ITも大抵筋肉でなんとかなる

気が向いたら技術的なことも書くかもしれないですが、技術的なこと=ITとは限りません。

Webサイト更新しました

メトロイド100%クリア version 1.5.xへ更新

www.geocities.jp

はい。前回1.2.xだったのに飛んでるじゃねぇかって話ですが、ブログ更新してなかっただけなので気にせんといてください。 今回の更新は下記です。

  1. フュージョン攻略チャートページにチャート内で取得・遭遇するアイテム、タンク、ボスの記載を追加
  2. 過去のコンテンツを更新
  3. その他誤字・脱字等の修正

1.のアレ

今まではページ上部に「Chart10」とかしか表示されてなくて、そのチャートが何をするチャートなのか今一つ分かりにくかったんですね。なので例えば攻略を途中から見た場合、一々内容を読まないとどの辺の進捗度なのかわからなかったわけです。
これはUX的によくねーなーということで何か対策がないかって話で、上記です。
どういうアイテムを取得してどういうボスに遭遇するかを記載することである程度のインデックスとして機能するのではなかろうかという推察の元、実装しました。これである程度中身を読まなくてもどの辺の進捗か分かりやすくなったと思います。もちろんボスと遭遇しなかったりアイテム1個も取らないみたいなこともあるので、100%ではないですが。

2.のアレ

私も絵をかいてたっぽくて発掘されたので一応載せておきました。腐らせるよりはいいかなと。

3.のアレ

まぁどうしてもありますよね…まだあると思いますけど直しました。

ってな感じで

1.の修正は割と大き目です。これが今回の目玉ですね。こうやって思いついたことをすぐに反映できるのが一人開発の強みだったりしますよね。まぁ開発ってもフロントしか使えないんですが。

Webサイト更新しました

メトロイド100%クリア version 1.2.xへ更新

これです。 www.geocities.jp 更新内容は下記です。

  • 全ページの読み込み速度改善
  • ページ内リンクの整備
  • トップへ戻るボタンの実装
  • お問い合わせフォームの不具合修正
  • 全体のレイアウト調整
  • その他不具合修正

コンテンツの内容的なお話

特に何か増えたってわけじゃないんですが、ページの読み込み速度を向上させてより快適に攻略を閲覧できるようにしました。攻略チャートは画像をふんだんに使っている影響で読み込みに1秒ほどかかっていますが、それ以外のページでは読み込み処理が分からないほど高速化できたと思います。チャートに関しても読み込み速度はかなり早くなったと思います。
あとはトップへ戻るボタンを実装したので、一番下までスクロールしてから上に戻るときに少し戻りやすくなったかなと。ただし広告が被るんであれなんですけどね…。ボスとかマップに関してもリンククリックしたらスクロールしてくれます。コンテンツ的なアップデートは以上ですかね。
お問い合わせフォームの不具合はしれっと直しておきました。バグってたの気づかなかったヨ。

技術的な話

高速化するに当たり、下記を実施しました。

  1. プリコンパイラの実装
  2. Handlebars.jsの導入
  3. js・cssの結合・minify
  4. できるだけDOMContentLoadedを使う

1.プリコンパイラの実装

ホームページを公開するに当たり、ジオシティーズというYahooのサービスを使っていますが、これは基本静的ファイルしか扱えません(課金すればPHPPerlCGIで動かせるみたいです。DBもSQLiteとかつかえた気がする)。なのでサーバサイドでHTMLを構築して返すというのはできないんですね。そうするとこんな問題があります。

1.HTMLの管理が煩雑になる

2.SEO的に不利な部分がでてくる

3.更新がめんどくさい

1.と3.は、いわゆるDRY原則が守れなくなることで発生する問題ですね。
2.はDRY原則を守ろうとするとこうなるって感じです。
1.は、サーバサイドでHTMLを構築できないせいで「ほとんど同じ構造で一部だけ違うHTMLファイルが量産される」という事態になるんですね。ディレクトリで表示ファイルを変えるわけですから(当然URLのエイリアスとかも使えない)、ディレクトリにファイルを配置しないといけないわけです。HTMLはほとんど同じ記述がすべてのファイルに入ることが多く(共通的に読み込むCSSやJSなど)、これを全ファイルに入れ込まないといけない。面倒ですね。
2.の話ですが、DRY原則を守ろうとすると、ディレクトリに配置するHTMLはガワだけおいておき(ガワが被ってる時点でDRYじゃないんですけどね)、JavaScriptで中身を当て込むという風になると思います。そうなってくると、当然Descriptionタグの中身を書き換えたりTitleを書き換えたりって話になります。そうすると、ロボットの認識的にちゃんと中身を拾ってくれるかどうか怪しいわけです。最近のロボットはJavaScript実行後のページを拾う、みたいな話をどっかで読みましたが少なくとも私が作ったやつは作りの問題なのか、そうはなりませんでした。JavaScriptで作ったDescriptionが読み込まれなかったということですね。titleとかh1も死んでました。となると、この辺は手作業でぺちぺちHTMLを編集することになります。面倒ですね。
3.は1.と2.の結果めんどくさいっていうアレです。もう少しビジネスライクな表現にすると「運用負荷が高い」とでも言いましょうか。ちょっと直すにも全ファイルを直さないといけないというなんとも修行みたいなことを強いられる羽目になるので、めんどくさいという表現を用いましたね。

これらの問題を解決するには、HTMLとHTMLに当てるデータを切り離して、デプロイ前にHTMLとデータをバインドするみたいな機構が必要だなーとか思っていて、「それってテンプレートエンジンっぽくね?」ってことでなんかそれっぽいアレを作りました。
残念ながら変数・定数・メソッドしか使えない(ループとif文は使えない)んですけどね。あとデータもDB使えないんでJSON読み込みまっせっていう仕様です。この辺の話は後日。

2.Handlebars.jsの導入

プリコンパイルしたところで、それって自動でHTMLファイルを事前に作りますよの話なので、それだけだと足りないんですよね。例えば更新履歴をトップページと更新履歴ページの両方に表示したいってなった時にどうすんねんって話があったりとか。あと顕著なのは、攻略チャートですかね。あれってHTMLは完全に1ファイルにしてあるんですね。なのでチャート1もチャート2も同じファイルなわけです。どうなってるかというと、getパラメータをJavaScriptで参照して、当該のチャートリソース(JavaScriptオブジェクトとして記述)を読み込んで画面を構築しているんですけど、そういうことはプリコンパイラでは不可能なんですよね。 なんでそんな面倒なことをしているかっていうと、チャートのページでは構造が大体決まっていて、

  1. ルートマップ
  2. 説明
  3. 説明に使う画像

ってな構造になっているんですけど、この辺のHTMLを書きたくなかったって言う理由ですね。同じ構造の繰り返しなのに同じように毎ページ毎ページHTML書くのはエンジニアとしてはナンセンスだなーーーと思ったので。ちなみに「画像1」みたいなのをクリックすると画像が表示されたり、ボスやアイテム名がリンクになっているのもJavaScriptでやってます。 こういうことがあって、一部描画はJavaScriptでやらざるを得ないなーということで、元々はテキストファイルにHTMLを切り出してAjaxで読み込んでいました。なんですけど想像以上に切り出すHTMLが増えたせいでページ読み込みのボトルネックなっちゃんたんですよね。しかもコード量も多くなるし。っていうので、テンプレートエンジンないかなーーーていう理由でHandlebars.jsにしました。採用理由はまた別途記事にします。

3.js・cssのminify

これは言わずもがなですよね。minifyしてファイルサイズを抑えてロードを短くしようっていうアレです。結合も似たような話で、何回も問い合わせに行くより一回の問い合わせでJS全部取ってこようキャンペーンって話です。JS取ってこないと画面の描画できないのでこの辺は地味に効果あった気がします。

4.できるだけDOMContentLoadedを使う

DOMが読み込まれる前に「var hoge = document.getElementById('hoge');」みたいなことすると「見つかんないよ!」って怒られますよね。なので大抵の場合下記のようにすると思います。

window.onload = function() {
    var hoge = document.getElementById('hoge');
};

ところがこれ、全部のリソースが読み込まれるまで待っちゃうので、ジオシティーズの場合 広告の読み込みも待ってしまう んですよね。ツール使って調べると広告の描画が一番のボトルネックになってしまっていたということがあり(2番目がGoogleからのフォント読み込み)、広告の読み込みは待ちたくなかったんですよね。ということで、すべてのリソースではなくHTMLのDOM読み込みが終了した時点で発火する「DOMContentLoaded」をできるだけ使うようにしました。こんな感じで。

window.addEventLitener('DOMContentLoaded', function() {
   var hoge = document.getElementById('hoge');
}, false);

こうしたおかげで広告の表示を待たずに画面表示を行なえるようになったので描画速度が圧倒的に向上しました。トップページの表示速度とか意味わからないぐらい改善できましたね。ちなみに第2のボトルネックだったGoogleからのWebフォント読み込みはあえてloadイベント発火時にやってます。フォント読み込み時間かかるので、うっかりloadイベントに登録したりするとそれ以降の描画が遅くなってしまうので。

やってみて

今回やってみてわかったことは、おとなしく最初からテンプレートエンジン使えって話でした。
あとこれは当たり前なんですけどやっぱりRDB使えた方が楽ですね。

12年前に作ったWebサイトを全面リプレイスしました

タイトルの通りです。なにはさておきリンクは下記です。

www.geocities.jp

改変内容について

コンテンツ面での対応

中身ですが、メトロイド任天堂から発売されているサムス・アランが主人公のアクションゲームシリーズ)の攻略コンテンツです。 コンテンツ的な対応で行くと下記の対応をしました。

  1. スマホ向けに表示を最適化
  2. 文章の修正
  3. 不要と思われるコンテンツの閉鎖

今のところこんな感じですかね。現在はメトロイドフュージョンメトロイド4)の攻略だけですが、メトロイドゼロミッションメトロイド5)の攻略も年内になんとかしたいなーと思ってます。 できればサムスリターンズの攻略も公開したいですけどね。 というわけで今後の展望的には下記です。

  1. ゼロミッション攻略の追加
  2. サムスリターンズ攻略の追加
  3. 初代メトロイドの攻略追加
  4. 旧コンテンツで需要のありそうなものを復活

技術面での対応

技術面では下記の対応です。一応IT屋さんなので書いときます。

  1. bootstrapの導入
  2. HTMLを最小限にし描画のほとんどをJavaScript(ネイティブ)で行なう
  3. メンテナンス性を高める
  4. Google AnalyticsGoogle Search Console)を導入する

って感じですかね。bootstrapはスマホ向けに必要だったので入れました。自分で書くとしんどいですからね。 2.は3.のための手段という感じです。URLを見てもらえばわかるのですが、「geocities」というサービスを使っています。 こいつが曲者で、サーバサイドプログラムが一切動かないタイプ(課金すればphpperlCGIで動かせるようです)なんですね。 とはいえHTMLべた書きは死以外の感想がなかったので、「じゃあテンプレートだけ用意してJavaScriptで画面作るかー勉強もかねて」という感じで、9割がたネイティブのJavaScriptで書きました。 ただし思っていたよりもJavaScriptのコーディングが重くなってしまいAngularJS使えばよかったと死ぬほど後悔しているところなので、次回からは素直にそうします。せめてVue.jsとか使えばよかった…。この辺は余力があるか協力者がいれば導入するかも。規模的にVue.jsの方がよさそうだけども…。あとはちょっと前にみたmustache.jsとかも面白そう。もう一度書きますけどお勉強になった以外はネイティブで書く必要全くなかった…。これは完全に見積もりミスです。 4.は実際問題どう見えてるのかとかいろいろ知りたかったので入れた感じです。技術的な話で行くと今後は

  1. SEO対策
  2. リファクタリング
  3. レンダリング速度の改善
  4. TODOコメントの消滅
  5. コメントを書く

とかこの辺でしょうね。SEO対策はやったら内容を書いてもいいかなーと思います。書いてて思ったけど新しいコンテンツ増やす前にフレームワーク導入してもいいかも。今回共通部品とか大きめのHTMLはajaxで読み込んでループ回してたりするんで、明らかに表示速度を下げちゃってるんですよね。この辺はまずったなって感じはあります。

作ってみて

正直とってもしんどかった…わけではないです。割と楽しんで作ってました。一番しんどかったのは文章をすべて書き換えたあたりですかね。ここは正直きつかったです。単純作業ですし。 あとサーバサイドでいろいろできないのは、エンジニアとしては両手足しばられた状態に近かったので、そこはきつかったですね。本当はDRYの原則を守って作りたかったんですけど無理でした…。 地味にうーーーーんこれは仕方ないけどなぁ…っていうのは広告ですかね。これのおかげで微妙にレスポンス遅くなるので。まぁ金払ってないから当然消せないんですけど。

ちなみにスマートフォンでちゃんと見られるようになったときは感動しましたね。「おおっ、なんならPCより見やすいのでは?」みたいな。今回は本当にそこを目指して作ったので、スマホ向けに最適化できたのはうれしかったです。 あとこれは本当に後日談的なアレですけど、お問い合わせフォームは完全自作です。Google Apps Scriptを使ってAPIを作ってます。残念ながらGoogle Apps Scriptは応答速度がそんなに早くないので読み込み中が長くなってしまうのがネックですが…。あれは完全に自分の趣味で自作しましたね。セキュリティ的にも外部のサービス使った方が楽なのは自明ですから。(あと昨今誰も使わないだろっていう)

中学生の頃に作ったコンテンツと向き合って全面リプレイスなんて夢にも思っていませんでしたが、予定通り10/1に公開できたのでそれはよかったです。今後は上に書いてある通りなので、いろいろ細かいところを行なっていきます。

メトロイドサムスリターンズが神ゲーだった件について

ついに…ついに…。

先週の9/15と言えば皆さんご存知、13年ぶりに発売されるメトロイド2Dシリーズ最新作「メトロイド サムスリターンズ」の発売日でした。メトロイドサムスリターンズは3DS専用ソフトで、ゲームボーイで1994年に発売された「メトロイドII Return of samus」のリメイク作品になります。そして前作の「メトロイド ゼロミッション」から実に13年ぶりの2Dメトロイドです。13年ですよ。13年前っていうとわたくしまだ中学生にございますよ。なんてこったパンナコッタ。

結論から言うと神ゲー

13年も待った挙句クソゲーだったらどうしようとものすごく心配しましたがそんなことはなかったぜ。正直過去作と比べてもそん色ないどころか「もしかして傑作と言われるパターンでは…?」というレベルの仕上がり。

1. 操作性が高い

過去の作品と比べても段違いの操作性の高さ。3DSというハードを余すことなく使い倒し、正直これ以上ないんじゃないかっていうぐらい高い操作性を実現していると思います。今回武器が増えたりアビリティがついたりと、過去作と比べかなりボリューミーだったにもかかわらずストレスなく操作できました。ただしアナログスティックということもありなれないとクッソ死にますが。

2. 世界観が「ザ・メトロイド

メトロイドと言えばダークな雰囲気で、暗い洞窟の中を探索しエイリアンと戦う…みたいなゲームですが、そのコンセプトを極めたような世界観とBGM。探索するのが楽しくなる感じです。

3. 過去最高のボリューム

私は初代メトロイドメトロイドフュージョン(4作目)・メトロイドゼロミッション(5作目)とプレイしてきましたが、どれも初見で4時間ほどあればクリアできるものでした。どちらかというとやり込みが主で、本編はサクッと終わる…みたいな感じだったのですが、今作はただクリアするだけでもものすごい時間がかかりましたね(初見ではクリアまでに14時間かかりました)。過去作をプレイしたときは中学生ということもあって自力ではクリアできず攻略をみながらプレイしていたので単純な比較はできませんが、とはいえ3倍以上の時間がかかっているわけですから、ボリュームがあったと言っていいでしょう。ただ長いって感じではないのでこれもすごいところ。

4. 戦闘が楽しい

操作性が向上したことと、今回は近接戦闘において「メレーカウンター」というのが導入され、敵の特定の攻撃に合わせてカウンターをしてからビームを撃ち込むと大ダメージを与えられるのですが、これがなかなかに楽しい。これのせいでテンポが悪くなるんじゃないかと思っていましたが、そんなことは一切なく、上手く調整されているなーーーという感想でした。もちろん特定のボス戦でも有効で、その際はボス戦用の特殊な攻撃になるのですがこれもまたカッコいい。

5. 探索が奥深い

マップが広大になったことでとにかく探索範囲も広くなりました。そのうえアビリティが増えたので、探索のやり方が非常に増え、探索が単純なものではなくなったと思います。終盤になるととりあえずパワーボム…みたいなところもありましたが、その辺も調整されていて、いろいろ組み合わせてアイテムを取得する場面が増えたなーーと思います。

6. ボスが多い

ボスが多いので、探索がダレないんですよね。いつボスと遭遇するか分からない(とはいえ一部のボスは接近すると接近していることがわかる仕様になっていますが)ので、常に緊張感がある感じです。

7. アビリティがよい

今回追加されたエイオンアビリティはどれも「これ強すぎじゃね…?」みたいなものですが、実際問題これがあることでゲームの難易度が下がることはないです(というか今作は今までと比べても難易度が段違いに高い気がするので…)。メレーカウンターがあることで敵が若干硬めですが、エイオンアビリティを駆使するとかなりテンポよく進めるので、考えられてる感じです。

8. メトロイドファンにはたまらない演出がある

とにかくプレイしてみてのお楽しみではありますが、ファンにはたまらない演出が多々あって、控えめに言って最高でした。

未だ興奮冷めやらぬ

発売されて4日ほど経過しましたが、いまだ興奮冷めやらぬ感じです。今のところNormalをクリアしてHardもクリアして、amiiboがないとアンロックできない「Fusion」という難易度でプレイしています。Fusionではサムスのスーツが2Dメトロイド4作目のメトロイドフュージョンでサムスが着ていたフュージョンスーツでプレイできる他、Hardよりも被ダメージが増え難易度がものすごい上がっているという仕様です。最初これがDLCだと散々たたいたんですけど、この難易度、同梱しなくて正解だった気がしますね。もはやほとんどオワタ式で「難易度って何だろう」ってなる難易度です。移動中うっかり雑魚に触ると死ぬという。こんなもんファンのやり込み以外やらないでしょうね…。ただamiiboすぐ売り切れるのは何とかしてほしいのと手に入らなかった人への救済措置はいい加減やってほしいですけどね。今作にケチをつけるとしたらそこぐらいですかね。せっかくの神ゲーなのでそこだけは惜しいですが…。

胸を張ってお勧めできるゲーム

残念ながら、メトロイドシリーズって日本では10万本売れるかどうかみたいなタイトルなのですが(アメリカでは100万本とかです)、今作は胸を張っておすすめできますね。ただしアクションが得意な人限定ですが…。

メトロイド、オモロイド

筋トレについて書きたい。

しばらく更新をしていませんでしたが、またしてみようかなーーーと思ったので。ですが、あまりITエンジニア業とは関係ないことを書くことが多くなると思います。もちろんたまには書くでしょうけど、それよりも筋トレのことについて書きたいという感じなので。

ITエンジニアこそ筋トレすべき

人間は根本的には動物であり、その構造は数千年前より変化していません。元来動物とは「動かないと死ぬ」のが基本ですし、人間も例外なくそうです。「動く」ということを前提に作られているためです。「動く」というのは昔でいえば狩りをしたり農耕をしたりするということです。そうやって体を動かすことで血液の循環であったり細胞の入れ替えを正常に行なえるようにしていたのですが、昨今の人間は動かなさ過ぎて、そういったことがうまく機能していないことが多いです。
元来人間に備わっている機能を十二分に生かし切れないがために病気になっているケースは少なくありません。そして、特にITエンジニアは一日中座っている仕事なので信じられないほどの運動不足です。不足というよりももはや無いと言って過言ではありません。この状態がいいわけがない。

なぜ筋トレか

運動しないといけないなら、別になんでもよくね?なんで筋トレ?と思うかと思いますがその他のスポーツに比べ圧倒的に楽だからというのが本音です。楽なんですよ。筋トレは、ガッツリやらないのであれば週2回1時間程度で十分です。実に楽。そのうえ、一人で黙々とやることもできるし、家でもできるのでコスパもよい(ちゃんとやるならトレーニングジムにいかないとですが)。他にもこんな理由で筋トレを推しています。

  • トレーニングメソッドは科学なので100%結果が出る(大小はある)
  • スポーツのパフォーマンスが上がる
  • メリハリのある身体を作れるので服が似合うようになる
  • 自己管理・体調管理が上手くなる
  • 目的は人それぞれなので競う必要がない

メリットはたくさんある

以前ツイートしたものですが、大体こんなメリットがあります。メリットしかないですね(ゴリ押し)。

最後に

身体を鍛えないことに対するデメリットはそのうち言及するとして、筋トレはしましょうっていうそういうゴリ押しを。記事の中でも触れましたが筋トレはれっきとした科学です。身体を効率的に動かすためには解剖学の見地からアプローチを行なったり、効率的に体を変えるために栄養学の見地からアプローチを行なったり、裏側にはきちんと裏打ちされた理論があるわけです。そういったものを利用するわけですから、そりゃ効果もあるよっていう話でした。

コンピュータが人間を超えることはない

我々、計算機を扱う人間ならば皆これに気づいているはず。コンピュータ、すなわち計算機が人間を超えることはありえない。現在のハードウェア構造では 絶対に越えられない。

自然言語とは

今まさに自然言語を理解しているわけだ。つまり、日本語や英語、フランス語、ドイツ語等々である。これらは自然言語と呼ばれる。これらを計算機が解釈することはある意味人類の夢の一つである。 今もって自然言語を正しく解釈することは難しく、研究の発展途上ともいえる。形態素解析、意味解析、人工知能の利用…どれを以てしても正しく解釈できた事例はない。

プログラミング言語とは

それに対し、プログラミング言語、すなわち形式言語というものが存在する。これの本質は0と1しか解釈のできない計算機に対する命令を抽象化することである。つまり自然言語とは大きく性質が異なるものである。おそらくこれに近しいのは、数学の数式などであろう。

なぜコンピュータは人間を超えられないのか

至極単純な話である。プログラミング言語予約語は、いくつだろうか?おそらくは30ほどではないかと推測する。イコールで、「プログラミング言語を扱う上で知っておかねばならぬ単語数」とも言い換えられる。予約語とは、プログラミング言語内で使用する英単語だと思ってもらってよい。 対して、中学英語に必要な単語数は1,200ほどであると言われている。言い換えると、日本基準で英語を中学レベルで扱うためには1,200単語ほど必要であるということだ。予約語と比べると圧倒的に多い。

そもそも論として自然言語ってなんだ?

自然言語については専門家に聞くのが一番早いだろうが、個人的見解では「人間の複雑な思考・感情をできるだけ正確に表すための抽象化手法」であると定義する。なんのこっちゃいって話なので少し嚙み砕くと、自分の考えや感情をどうやって正確に相手に伝えるか?ということに重きを置いたツールだと思ってもらえばよい。つまり、人間の複雑な思考を表現するためには当然ながら30単語では足りないのである。ちなみにネイティブだと30,000単語以上を操るというから、1,000倍以上である。つまり計算機と人間とでは複雑さが単純な数値で表すと1,000倍以上違うのである。ちなみにこれは単語数だけであるから、文法なども組み合わせるともっとだ。

シンギュラリティの可能性

話が飛ぶようだが実はアナログ的であるのがこの話だ。計算機が人間を超える可能性は、先の通りなので100%否である。そもそも自分の持っている思考を抽象化したときの複雑さが全くもって異なるからである。厳しいことを言ってしまうようだが、もし今の仕事がAIにとってかわられるような仕事であるならば、それはその程度の価値・複雑さしか有していないということになる。すなわち、「人間でなくともできてしまう、仕事ではない『作業』である」ということになってしまうわけだ。
人間のような複雑な思考を持っていなければできないような仕事はこの世に複数ある。一部の人が信じてやまない、プログラムを書かない時代も、残念ながら来ないと言っていいだろう。正確には、設計書からプログラムを自動生成する時代は来るだろうが、そのころには設計書がプログラムと呼ばれているだろうということである。この辺りはコンパイラの歴史を調べていただければ納得できるだろう。結局のところ「知的活動」のようなものは残る。もう少し具体的に言おう。「英知」のようなものは残り続けると言っていいということだ。
だが残念なお知らせもある。今のは、ハードウェアの形態が全く変わらない場合の事象を指している。つまり、ハードウェアの形態が人間に近しくなった場合、そしてそれが自分自身で成長できるようになった場合は、正直分からないということである。そうなったとき、どう生きなければならないかは分からない。しかし、今生きる分には何が大切かは自明なはず。それを大切にしたいと思う今日この頃である。

型宣言なし言語への偏見をなんとかしたい

なんというか、型宣言のない言語への偏見がすごいので何とかしたい。

そもそもデータ型の存在意義とは

データ型の存在意義というのは、「その変数に対する抽象化」であるといえます。例を交えましょう。

a = 255

これはaという変数に255を代入しています。ということは、aという変数のデータ型はintであることが推測できます。

ではこれは?

a = b

分かりませんね。困りました。

という状態を防ぐのが型宣言です。データ型というのはその変数が取りうる値の性質をグループ化して表現することで、「具体的に何が入るかは分からない。ただ俺にはintしか入らねぇぜ!」という状態を作れます。そしてそれを事前に宣言するのが型宣言です。
こうすることで、intをbooleanと間違えて if (a)などとしなくて済みます。なぜならコンパイル時点ではじいてくれるためです。

型宣言がある場合の例

型宣言があることによるメリット

例えば

int a = 0;

としてあればaにはintしか入らないため、「この変数には文字列が入っているのか?それとも浮動小数点数か?」といったチェックを自動的にしてくれるようになります。これは潜在的なバグを引き起こしにくくなることを意味します。例えば、

a = 1;
b = 2;

とあったとして、a + bは当然3になるはずです。しかし何かのはずみでデータ型がstringになっていたとすると、a + bは12になってしまいます。仮にこの計算結果をどこかで使っていると、計算が合わなくなりバグを引き起こします。がしかし文法的に間違っているわけではないのでコンパイルエラーにはなりませんし、例外ログにも残りません。トレースの難易度が上がります。
そこで、

int a = 1;
int b = 2;

としておくことで、a + bが3になることを担保できます。型宣言にはこういった安全装置の役割もあるのです。

型宣言があることによるデメリット

一方、型宣言があることによってデメリットもあります。例えば、こんなもの。

double pi = 3.14;
int x = pi;

これでは、xに代入される値は3となってしまい、期待通りの結果となりません。また、型がオブジェクトの場合は少々やっかいなこともあります。例えば、これ。

List<int> list = [0, 2, 4, 6];

Javaにおいてこの記法は許されません。同等のことをしようと思うとこうしないといけません。

List<int> list = new ArrayList<int>(Arrays.asList(0, 2, 4));

いささか冗長ですね。そう、型宣言は自動でエラー検出をする代わりに冗長なのです。これは、プログラミングを熟練すればするほど鬱陶しく感じることでしょう。

型宣言がない場合の例

型宣言がないことによるメリット

さてはて、型宣言がない場合はどうでしょう。同じ例を取ります。

pi = 3.14;
x = pi;

xには正確に3.14が代入されます。これは期待通りでしょう。さらに、型がオブジェクトでも厄介なことにはなりません。

list = [0, 2, 4, 6];

Pythonであれば、これはlistオブジェクトとして解釈されます。制約はありません。 つまり、見たまま・やったままを実行してくれます。これは楽です。こちらが明示的に入れ物を変化させることなく入れ物を適切に変更してくれるためです。入れ物を変更するのは大変です。時にはデータ構造をも変更しなければならないほどです。これは純粋なロジックを記述するとき邪魔になります。なぜならば、ロジックを考えることに集中できなくなるからです。本質は入れ物の中に何が入るかなのに、どの入れ物を用意するかで多くの時間を消費することになるからです。

型宣言がないことによるデメリット

a = 1;
b = 2;

とあったとして、a + bは当然3になるはずです。しかしプログラマのミスでうっかり

a = "1";
b = 2;

などとしてしまっていると、a + bの結果が予測できなくなります。もし暗黙的にデータ型を変更されでもしてしまったら、a + bが3になるか12になるか、動かすまで検討がつきません(もしくはよほど言語仕様に詳しくない限り)。ただしPythonは異なるデータ型同士の足し算はエラーとしてくれます。ですので、どちらの結果になるか分からないではなく、実行時エラーとして知らせてくれるためこちらが考えるコストは幾分か少なくなります。

結論

型宣言がない場合のデメリット、なんだか微妙ですね。そもそも動かす前のエラーは、IDEが検知してくれない限り我々は知る由もありません(コンパイル時に知らせてくれるじゃないか!というかもしれませんが、インタプリタ型にとってはコンパイル=実行であるため、強く型付けされていれば大差ないのです)。そう考えると、残念ながら型宣言がないことについて、コーディング時はあまりデメリットはないということです。むしろ型変換を行なうロジックを組まなくて済むため、本質に集中できることでしょう。ただし残念ながら実行速度はデータ型があった方が上です。また、PHPJavaScriptなどの弱い型付けの場合はこの限りにはありません 。多少データ型がおかしくても実行されてしまうため、やっかいなバグを生みやすくなるでしょう。つまり、型宣言があるかないかではなく強い型付けなのか弱い型付けなのかで議論した方がよい ということになります。特にC#などは型宣言をしなくとも(正確にはvarなどで記述する)、型推論をしてくるため幾分か楽であると言えるでしょう。強い型付けの場合は、型宣言など行なわなくともほとんどの場合不整合が起きないです。
ということで、これからは
強い型付けor弱い型付け
で議論をしたいなぁという結論でした。ちなみに私は型宣言は足かせでしかないと思っています。コンパイル時にエラーがみたいな話は聞きあきました。動かせばわかることですし、仮に動かすのが難しいのであるとするとそれはそれで大問題です。もしどうしても性質上動かすのが難しいということであれば、テストコードを書けばよいのです。テストコード、書きましょう。