2014年の反省と2015年の目標

あけましておめでとうございます。
2012/01/08に始まったこのブログも
3周年を迎えました。
2013年は117記事でしたが、
2014年は72記事となって減少傾向です。
細かい Tips などは Qiita に
書くようになったので
wada811(Qiita) もよろしくお願いします。
昔からの人も最近からの人も
2014年、お世話になりました！
2014年のエンジニア人生を振り返って
2015年の目標を立ててみようと思います。

2014年

結婚した

撮った写真を披露宴会場のスクリーンに表示するシステムが3万円くらい、と
結婚式の2週間前に TV でやっているのを見て
こんなのすぐできる！1人日程度だろ？と思って写真アップロードシステム作ったのは良い思い出でした。
実際は細切れにしか作業できなかったので総日数としては3日くらいかかりましたが。
借りてたさくらのVPSにPHPをインストールしてなかったとか
ドメインを取ってなかったので契約からスタートとか色々ありましたが、
開発だけなら1人日程度でできたと思います。
wada811/wedding.wada811.com
とにかく時間がなくて画面も3枚だけだったので手っ取り早く素の PHP で作りました。
脆弱性とかはないと信じたい。。。
開発で一番時間がかかったのは PDO の薄いラッパーを探すことで、
プリペアドステートメントでクエリ発行できるやつが見つからなかったので仕方ないから自分で作りました。
あとは、CSS3 の transform をアニメーションの調整くらい。

関連記事

さくらのVPSにスタードメインで取得した独自ドメインを設定してみた
jquery.transform.js で CSS3 の transform をアニメーションさせる
exif-js と ios-imagefile-megapixel でスマホからの画像アップロードのプレビュー表示に対応する

Androider としての技術力を更に高める

どちらかというとライブラリ作ってた感じ。
wada811/Android-DialogFragments
wada811/Android-Material-Design-Colors
カメラのライブラリも作ってほぼほぼできていたけど放置していて完成したのかどうかも忘れている現状…。
カメラのライブラリは設計がいいのかどうかもわからなくて、
他の人がカメラアプリ作るときどんな感じに作っているのか知りたい。
The Android Arsenal - LandscapeVideoCameraとか、
そこの See Also とか見ればわかるかな。

新しい言語を学ぶ

Ruby on Rails 始めました。
Qiitaで Ruby とか Rails の知見を共有しています。
View は Slim で書いていて、もう PHP で、HTML で、というのには戻れない感じです。
そういう感じなのでブログも生の HTML を書くのが面倒になってきて Markdown で書きたいなぁという感じです。

OpenGL を学ぶ

やりませんでした。たぶん来年もやりませんね。

UnitTest / CI を学ぶ

Rails で Rspec を使ってテスト書いたり、 Guard でファイル変更を監視して自動的に Rspec を実行とかやった。
Rails はとにかくすぐ壊れる印象なのでテストがないとリファクタリングできないという感覚になっている。
テストを書く習慣が定着してるのはそういうことか〜という感じです。

個人でのプロダクトを出す

ライブラリをプロダクトと呼ぶかは微妙だけど、それ以外で言うと何もないなぁという感じです。
ひたすら GitHub Star を集めたり Qiita Stock を集めたりしてモチベーションを保っていた。

収入を増やす

一応増えたけどコスパ良くない。税金が重い。社会は厳しいという感じ。

2015年

もっと Android

あんまり Android で DB を使ったアプリを作ってないので作りたい。
RxJava, RxAndroid, Lombok あたりを使ってモダンな感じで作りたい。
Material Design に対応したい。
この3本で頑張っていこうと思います。

もっと Ruby on Rails

まだ1ヶ月やっただけなので、もっと経験を積みたいです。
アプリのバックエンドで使ってみる。

もっと UnitTest / CI

コミットしたらテスト実行されて…という環境を作る。

個人でのプロダクトを出す

新しいものを考えてはある。あとは作るだけ。

収入を増やす

コスパあげたい。

ブログを移行する

GitHub Pages に移行して Markdown で記事書きたい。
でも GitHub Pages をやめちゃった人がいて、面倒なのかとか気になっているところ。
ブログのカスタマイズにはあまり時間を掛けたくないので悩んでいる。

2015年もよろしくお願いします！

さらなる飛躍の年にするべく頑張ります！

2013年の反省と2014年の目標

あけましておめでとうございます。
2012/01/08に始まったこのブログも
2周年を迎えました。
2012年の208記事とまでは行きませんが
2013年も117もの記事を書けたので
このブログのアクセスも増えていきました。
昔からの人も最近からの人も
2013年、お世話になりました！
2013年のエンジニア人生を振り返って
2014年の目標を立ててみようと思います。

2013年

Android アプリを何本か作った

まず、プライベートではDevCameraというカメラアプリを作りました。
これは会社でカメラアプリを作った際に無音連写が実装できずに悔しい思いをしたためと、
会社のカメラアプリがヒットしたのでその引合でカメラアプリ開発の依頼が来るだろうという予測のもと、
個人で技術調査的に開発したアプリです。
実際にカメラアプリの仕事を依頼を受けて開発しましたし、
カメラアプリ開発以外の仕事にも広がったので大変良い結果になったと思います。
本当は DevCamera 経由で仕事の依頼が来て、技術で仕事取ってきたどー！ってしたいので
もしカメラアプリの開発の仕事がありましたらこちらにメールいただけると嬉しいです。

カメラ機能は爆速で開発できるようになったのでこれ↓を作れば良かった。仕事してる場合じゃねぇ！
「きすしよ！」ヤフー！があの「天才1」が考案したアプリを爆速で本当に開発ｗｗｗ | あんどろいどスマート

生産性の向上

2013年の目標であった「生産性の向上」はある程度達成することができたと思う。
Sublime Text 2 のカスタマイズはある程度使いやすくなったので完全に放置しているけど
Android のユーティリティ的なライブラリを充実させていったので開発速度は結構上がってるはず。

巳年なのでPythonを学ぶ？

Sublime Text 2 のプラグインを作るために学ぶかなと思ったけどやらなかったね。
必要は発明の母だから必要になっていない場合はモチベーション低くてやらないね。たぶん今年も。

新しい言語を学ぶ

新しいプログラミング言語を学ぶとかそんなことはなかった。
まぁ Android の Fragment とか Loader などの Android 3.0 以上の API を学んで使っていたのでアリ？
去年と比べたらグッと Android (Java) の技術力が上がったと思う。

UnitTestを学ぶ

Android の一部アプリで少しやったくらい。いかんせんカメラアプリとかだとやりにくい。

CI(継続的インテグレーション)を学ぶ

UnitTest と合わせて CI を回すと考えていたけど UnitTest をやっていないので CI も、という状況。

個人でのプロダクトを出す

Android アプリ「DevCamera」を出しましたね。
月一でアップデートするようにしています。じわっと 1000 DL 超えました。
まだまだやりたいことは多いのでアップデートしていきます。

収入を増やす

OpenGL を学んで DevCamera でフィルターの販売とかしたい。アプリ内課金の練習にもなるし一石二鳥。
応用情報技術者を取っていない。春に取ろう。
Amazon アフィリエイトは料率下がってるし、書評を書いてないしで減収。悲しい。
Google AdSense はブログのアクセスが増えて少し増えたけど飲み会にも行けないレベル。もっと増やしたい。
そして、今年もヘッドハンティング的なメールを頂いた。年末はそういう時期なのかな？
今年は去年と違ってヘッドハンティング会社ではなく、
開発会社から直接興味があったらお話でもというメールだった。
ブログの目的の一つがセルフブランディングなので技術者としての価値を認めてもらえたというのは
ブログがしっかり役割を果たしていて凄く嬉しい。
しかもカメラアプリを作っているようで、DevCamera が目に止まったのかなぁとか思ったりして
まったく DevCamera は大成功だな！

2014年

Androider としての技術力を更に高める

実装能力だけじゃなくて細部のクオリティの高さとか使った時の気持ちよさなんかを上げていきたい。

新しい言語を学ぶ

アプリのバックエンドとかを Ruby とかで作ってみたい気はするけど
Mobile Backend Starterとかあるしどうかな？
Ruby on Rails を動かすのに Heroku とかお金かかっちゃうからその辺をまかなえる副収入とか欲しい。

OpenGL を学ぶ

DevCamera にフィルター機能を追加してアプリ内課金で販売とかしたい。
画像加工系はカメラアプリ作ってるとそこそこ需要あるからできるようになっておきたい所。

UnitTest / CI を学ぶ

継続的なサービスとかじゃないと UnitTest や CI は意味が無いので
まずは継続的なサービスを作る所から？先は長い。

個人でのプロダクトを出す

今のところは DevCamera で一通りの実装をするかなぁ。更にもう一個作るかどうかは微妙。
DevCamera のクオリティアップだけでやることいっぱいなので今年は育てるフェーズになると思う。

収入を増やす

応用情報技術者を取る。アプリで収益を出す。ネット上で技術書代くらいは稼ぐ。
仕事も頑張って昇給/賞与の増額を狙う。頑張れば正当な評価も良い機会も与えられるので頑張ろう。
現状は特に不満もないし、やればやっただけ成長できるし、
生活基盤も構築されてきて遠くには移りづらいので転職は考えていないかな。
稼がねば。

2014年もよろしくお願いします！

さらなる飛躍の年にするべく頑張ります！

2012年の反省と2013年の目標

あけましておめでとうございます。
2012/01/08に始まったこのブログも
1周年を迎えました。
おかげ様でこのブログのアクセスも
順調に増えて行きました。
12月にこの記事で話題になり
大きくアクセスも伸びました。
昔からの人も最近からの人も
2012年、お世話になりました！
2012年のエンジニア人生を振り返って
2013年の目標を立ててみようと思います。

2012年

Excel VBAを学んだ

マクロ組めれば普通だったら便利屋さんになれる。ちょっと触るくらいならいい。もうあんまりやりたくない。

Objective-Cを学んだ

iPhoneアプリを作ろうということでガッツリやったり。これで一応iPhone/Androidできるようになった。

PHPを学んだ

なんでもアリな感じでﾋｬｯﾊｰって感じですね。なんでもアリすぎて他人のコードを受け付けなくなりそうな感じ。

SQLを学んだ

SQLマジアツい。楽しい。いろんなクエリ組んでて一通りできるようになったと思う。たぶん。

生産性の向上

NetBeans触ってて使い勝手悪くて微妙な感じなので環境を見直して効率を上げたい。

UnitTestを学べなかった

UnitTestできて一人前よねーみたいな風潮があったからできるようになりたかったけど結局触れれず。

2013年

生産性の向上

Sublime Text 2をカスタマイズして開発スピードを上げたい。

巳年なのでPythonを学ぶ？

Sublime Text 2のプラグインはPythonで書くのでPythonを学んで(出来れば3系だけがいいなー)
プラグイン作って生産性の向上を果たすかもしれない。

新しい言語を学ぶ

上のPythonも含めて毎年なにか一つ新しいプログラミング言語を学びたい。

UnitTestを学ぶ

他にも学ぶべきことがいっぱいあってプライオリティ下がり気味で後回しになりがちだけど今年中には…！

CI(継続的インテグレーション)を学ぶ

Jenkins氏と友だちになりたい。ちょこちょこ調べて導入していきたい。

個人でのプロダクトを出す

iPhone/Androidアプリ、Webサービスなんでもいいから一つくらい個人のプロダクトを出したい。

収入を増やす

応用情報技術者を取るなり、生産性を上げてプラスアルファの働きをしてバリューを生み出すなりしよう。
そういえば思い出したけどヘッドハンティングのメール来てたし、転職という手もあるかもしれない。
個人プロダクトで稼ぐでもいいし、ネット上で何らかの方法で稼ぐでもいい。
個人の時代と言われるこの時代を一人でも生き抜くことができる、稼ぐことができるような力が欲しい。

2013年もよろしくお願いします！

さらなる飛躍の年にするべく頑張ります！

Webプログラマーになる前に学ぶべきこと、知っておきたかったこと

新米Webプログラマー@wada811がプログラマーになる前に学ぶべきこと、知っておきたかったことを
これからWebプログラマーになる人に向けてまとめてみました。

心構え

プログラマとして生きるための心構えとして情熱プログラマーを読んでおくのはオススメだと思います。
研修先から帰る新幹線の中で読み終わる程度の分量だったのでぜひ読んでおいて欲しいです。
さらっと読めてしまうけど学ぶことが多いので何度も読んでしまうお気に入りの本です。
コードについてはリーダブルコードを読みましょう。[書評]リーダブルコード The Art of Readable Code
志高く、良いコードを書こうという気概があれば技術者として伸びていけると思っています。こちらもぜひ！
あと、ブログを書こう！私がプログラマとしてブログを書く事をオススメする8つの理由 | DevAchieve

スキル

HTML/CSS

Web系なら基本中の基本です。
HTML5/CSS3とかアツいですし、HTML5の仕様策定も完了したのですが
ユーザーが使用するブラウザが対応していないことも多いのでまずは基本のHTML/CSSを抑えましょう。
ということで、Web標準の教科書―XHTMLとCSSでつくる“正しい”Webサイトはオススメです。
結構習うより慣れろ的なところがあるので既存のページをいじくりまわすだけでも勉強になるかと思います。

プログラミング

あんまり好きじゃないですけど最初はやっぱりC言語からなのかなぁという気がします。
最初はCの絵本や新版 明解C言語 入門編なんかを半年くらい挫折を繰り返したり
プログラミングの宝箱 アルゴリズムとデータ構造 第2版でちゃんとアルゴリズムを学んだり
AIZU ONLINE JUDGEのVolume100のものを一通りやったりとある程度できるようになるまで頑張りました。
今は3分動画でマスターする初心者向けプログラミング学習サイト - ドットインストールがあって
通信添削もしてくれるそうですからプログラミング学習については困らなそうですね。

JavaScript/jQuery

軽く知っていると実装に幅が出て捗ります。
ガッツリ習得してなくても何とかなっているけど基本くらいは知っておきたいですね。
プロになるためのJavaScript入門が最近出て、書評とか見る限り良さげだったので読むと良さそうです。
ガチでやるならJavaScript 第6版とJavaScriptリファレンス 第6版は役立ちそうです。

正規表現

もしかしたらJavaScriptより先にこっちを習得しておくべきかもしれません。
めんどくさいテキスト処理などを一発で片付けることができたりとかなり捗ります。
習うより慣れろで覚えてしまったのでどの書籍が参考になるとかは挙げられないのですが頑張って覚えましょう！

PHP

全く知らないのでは実務で困ることが多いと思うので概要をプロになるためのWeb技術入門と
プロになるための PHPプログラミング入門で抑えておけばなんとかなるはずです。
プログラミング自体が初めてでなければめっちゃ便利なC言語の上位版みたいな感じなので大丈夫だと思います。
あとはPHP: PHP マニュアル - Manualが詳しいので関数とかをマニュアル見れば使いこなせるかと思います。
フレームワークはCakePHPがよく使われているますが、入社時に習得してなくても
CakePHP Cookbookというドキュメントがあるので入社後に習得していけば大丈夫です。

SQL

PHPに合わせてSQLも学ぶ必要がありますが、入社時にはデータベースの概要がわかっていれば十分でしょう。
マンガでわかるデータベースがわかりやすかったです。[書評]マンガでわかるデータベース | DevAchieve
SQL ゼロからはじめるデータベース操作も読んでガリガリSQL書けるようになっていると凄いです。
[書評]SQL ゼロからはじめるデータベース操作 | DevAchieve

バージョン管理システム

SubversionかGitのどちらかを知っていて軽くでも使ってみていると実務で使う際に理解が早いかと思います。
個人で使うならGitだと思うので入門gitとか読んで実際に使ってみると良いんじゃないでしょうか？
GitならGitHubでソースコードを公開できるので何か作って公開しておくとヘッドハンティングとか来るかも？

資格

資格を持っていなくても基本情報レベルの知識はあった方が良いんじゃないかと思います。
僕は基本情報は入社直後の春に取りました。基本情報技術者試験を受験するまでに使った参考書3冊
基本情報が取れればちょっと勉強すれば応用情報も取れると最近聞いて来春受験に向けて勉強してます。
資格を取ったら祝い金とか貰えるとこなら頑張るのもいいと思います。

おわりに

こう見るとWebプログラマーに求められる技術は結構幅広いですね。
広く深い知識を習得していかなければなりませんので日々勉強が必要です。
万能選手でなければならないけどもスペシャリストでもなくてはならない、
それでいて一番の下手くそでもいたい。(情熱プログラマー)
こんな師匠がいて導いてくれていたらと思い、記事を書いてみました。
僕のWeb系の師匠になってくれる人を探しています！

[書評]リーダブルコード The Art of Readable Code

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
Dustin Boswell
オライリージャパン
発売日：2012-06-23

ブクログでレビューを見る»
コードは理解しやすくなければならないという考えのもと、
理解するための時間を最短にするための実践的なテクニック集を解説している本。
アーキテクチャとかデザインパターンとかではなく、
もっと基本的なことについて書かれているので
この本の内容を当たり前だと思えるようなプログラマーになろう！

目次と訳者の解説が公開されているので気になったら読んでほしい。
O'Reilly Japan - リーダブルコード http://www.oreilly.co.jp/books/9784873115658/
リーダブルコードの解説 http://www.clear-code.com/blog/2012/6/11.html

個々の内容について書いたらリーダブルコードの内容をリライトしてしまうのでそれ以外について書く。
この本の原典は以下の書籍だろうか。
あわせて読みたいで高品質なコードを書くための書籍として紹介されていた書籍だ。
Code Complete第2版〈上〉―完全なプログラミングを目指して
Code Complete第2版〈下〉―完全なプログラミングを目指して
リファクタリング―プログラムの体質改善テクニック
プログラミング作法
達人プログラマー―システム開発の職人から名匠への道
Clean Code アジャイルソフトウェア達人の技
これらをいくつか読んでいる人にはおそらく必要のない本だろう。
どれも名著と呼ばれ、内容的にも値段的にも重量級の書籍ばかりだ。
プログラミングに関して意欲と費やせるお金と時間があるのならば原典を読んだほうがいいと思う。
それらを持ち合わせていない人や手っ取り早くテクニックを知りたい人には最適の本だ。
あとは他人のケツを拭きたくない人は教育用に読ませればいい。230ページ程度だからすぐに読める。
読み終わったら(本の内容に理解してくれたら)すぐにコードはマシなものになるだろう。

リファクタリングやTDDが一人前のプログラマーならできて当たり前みたいな雰囲気が最近あるけど
リーダブルコードを書くことも当たり前な雰囲気ができて欲しいですね。当たり前すぎて言われてないだけかな？

追記: 良い名前をつけるためのWebサイト

リーダブルコードでは良い名前をつけろと言われるが日本人に英語の細かいニュアンスの違いを把握して
命名するのはなかなか大変だと思うので類義語・対義語を調べるには以下のサイトがいいと思う。
Thesaurus.com | Find Synonyms and Antonyms of Words at Thesaurus.com
フォームから検索すれば定義や類義語・対義語がわかる。Synonymsが類義語で、Antonymsが対義語だ。
適切な意味の単語を選ぶことに時間をかけるプログラマーはブックマーク必須だ！


リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

[書評]達人プログラマー システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道
アンドリュー・ハント
ピアソンエデュケーション
発売日：2000-11

ブクログでレビューを見る»
様々なところで語られるプログラマがやるべきことの原典。
まだ「こうあるべきだよな！」と共感するほど
システム開発に携わっていないが「こうあるべきなんだ」と思って
本書に書かれていることを実践していきたい。

プログラマかくあるべし！みたいな本。
なんとなく情熱プログラマーとかの心得本みたいな印象があったけど違った。
より実際のプログラミング、システム開発に近いところでのプログラマがどうあるべきかを説かれている。

巻末に達人プログラマーになるためのヒントがまとまっているので
定期的に達成度をチェックすると面白いと思う。
いろいろできるようになりたいことはあるけどとりあえずユニットテストをするようにしたい。
ひよっこプログラマなので半人前なのだけれども、テストができないと半人前感が半端無い。

また折を見て達成度をチェックしようと思う。

私がプログラマとしてブログを書く事をオススメする8つの理由

だって人間は忘れる生き物だから

一回やってしまえば終わりな環境構築とか滅多に書かないコードとか全部覚えてられますか？私は無理です。
だいたいのことは検索すれば出てくるので、その都度検索すれば良いと思うでしょうが私はそうは思いませんでした。
私は面倒な事が嫌いです。同じ事を何度も検索するのが嫌いです。

その姿は毎度のようにお道具箱をひっくり返す小学生に似ていた

ネットは他人のお道具箱です。
ゴミのようにグシャグシャになったプリント混じりのお道具箱の中から
必要な道具を時間掛けて探すなんて苦行に何故耐えられるのですか？
私は面倒な事が嫌いなんです。
道具を他人のお道具箱に入れてる限り、その道具は自分の道具のようにすぐに取り出すことは出来ないのです。
頭の容量が無限大にあって、どんなに時間がたっても劣化せずに
素早く読み出せるのなら全部覚えてるのでもいいのでしょうけど…。

ブログは私のお道具箱

残念ながら少なくともわたしの脳はそのようにはできていないので全てを覚えておくことは不可能です。
かと言って忘れたら再び他人のお道具箱を漁るのは嫌です。
私は面倒な事が大嫌いなので。
じゃあどうするかと言ったら自分のお道具箱に綺麗に整理整頓して入れておくしか無いわけです。
勝手知ったる自分のお道具箱なら必要な道具を取り出すことは容易に行うことができます。

どんなに便利な道具も他人のお道具箱に入れてあったら他人の物だ

道具を借りている以上、それ以上のものはそこから得られません。
複数集めれば十分な知識を得られるかもしれませんが、忘れたら全て調べ直しです。
面倒な事が嫌いな私はそんなことを許せるはずもありません。
Googleの気分次第で見つからなくなったり、情報自体が消え去ってしまうかもしれないのですよ。
ブログに書いて自分の物にしてしまえば全て自分の知識になるのです。

勉強するのにノートを書かないなんて

そういうことでプログラマの方には是非ブログを書くことをオススメしたいのですが、
「他の人がもう書いてるから書く必要がない」とか「拙い知識で書いてもしょうがない」とか返されることがあります。
でもそんなことはないと声を大にして言いたい。
前者は是非他人の道具を自分の物にして欲しい。複数ページを参照しているのならまとめることで体系化した知識にできる。
後者は自分のために書いた方がいい。コードを見て、そう書いた理由が、関連知識が全て思い出せますか？
両者とも何かを学んだならブログに書こう。

書けば覚える、少なくとも書いたという事は

やはり人間、ブログを書いても時が経てばどうしても忘れてしまいます。
でも不思議とブログに書いたという事は覚えていたりするものです。
その際にちゃんとブログに書いてあれば読み返すだけで思い出せます。

書くなら詳しくわかりやすく

忘れてしまった未来の自分のために詳しくわかりやすく書いた方が良いのはもちろん現在の自分にもメリットがあります。
詳しくわかりやすく書くためにはそれ相応の知識が必要になるので必然的に調べることになるので理解度が上がります。
調べることで勉強にもなるし、より良い方法を見つけることもあるので「詳しくわかりやすく」を心がけましょう。

調べるときには必ず原典にあたる

2次ソース、3次ソースを参考に書かないほうがいいです。間違っていたり、古くなっていたりすることがあります。
必要なことしか書かれていないことが多いのでそれが知識の上限にならないようにするためにも必ず原典にあたりましょう。
これができている人はやはり凄いです。

さいごに

本当は[企画]なんでブログ書こうと思ったのさ！『あなたのブログ始めたキッカケ教えてください』 #myblogstartの
企画に乗った記事を書こうと思ったんだけこの記事をキッカケにして欲しいという気持ちが強かったのでシフトしてしまった。

一緒に読んでほしい：「師匠になる」 - 情熱プログラマー ソフトウェア開発者の幸せな生き方

[書評]「プロになるためのWeb技術入門」なぜ，あなたはWebシステムを開発できないのか

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか
小森裕介
技術評論社
発売日：2010-04-10

ブクログでレビューを見る»
Webシステムを開発する上で必要な基礎知識を
Webアプリケーションの発展の歴史とともに学ぶことができる良書です。
なんとなくプログラミングできて、なんとなくフレームワークやデータベースを扱えて、
そんなプログラマがWebシステムを理解することができます。
Web系の企業でちゃんとしたエンジニアになりたいなら読んでおくべき一冊だと思います。

書籍案内：『プロになるためのWeb技術入門』―なぜ，あなたはWebシステムを開発できないのか｜gihyo.jp 技術評論社
『プロになるためのWeb技術入門』サポートサイト

AndroidとかiOSとかでアプリばっかり作ってるからか、
Webシステムを作るための基礎知識が全然ありませんでした。
言葉は聞いたことあるけど理解していない、
実装する際に何がスタンダードなやり方なのか知らないという状況で、
コレはまずい！と思って急いで買ってきて読みました。

Web系の企業でWebシステムを開発するエンジニアは
この本に書いてある内容を理解していないとヤバいですね。
それくらいWebシステム開発の基礎知識が詰まっています。

半日くらいぶっ通しで読めば読み終わるくらいには読みやすいので
基礎知識に不安がある人は買ってきて土日で読むといいです。
読んだ翌週にはきっと生まれ変わったような感覚になれます。というかなりました。

目次を見ると古い技術から解説してあって今更そんな事知って何になるんだ、と思うかもしれませんが
Web技術の発展の過程で何が問題になってどのように解決していったのか、
どのように現在の高度化した技術が生まれたのかがわかるので
現在の技術、これからの技術を理解するのに役立ちます。

またWebシステムで必須のセキュリティ対策についてもわかりやすく書いてあり、
いきなり徳丸本を読むのはハードルが高いなぁって人にもオススメです。
他にも、戻るボタン問題やダブルサブミット問題についても書かれているので
困っている人には今すぐ役立つ内容になっています。

Web系企業ならこの本を研修とかで読ませればいいのに、と思いました。

[書評]プログラムはなぜ動くのか 第２版知っておきたいプログラムの基礎知識

プログラムはなぜ動くのか　第２版　知っておきたいプログラムの基礎知識
矢沢久雄
日経ソフトウエア
発売日：2007-04

ブクログでレビューを見る»
プログラムとハードウエアの関係性を説明した本です。
基本情報技術者試験を受けるなら基礎知識として知っておきたい内容です。

計算機科学的な内容と基本情報技術者試験に関係あるような内容の本です。

情報処理推進機構：情報処理技術者試験

情報処理技術者試験とは

情報処理技術者試験は、「情報処理の促進に関する法律」に基づき経済産業省が、情報処理技術者としての「知識・技能」の水準がある程度以上であることを認定している国家試験です。
情報システムを構築・運用する「技術者」から情報システムを利用する「エンドユーザ（利用者）」まで、ITに関係するすべての人に活用いただける試験として実施しています。特定の製品やソフトウェアに関する試験ではなく、情報技術の背景として知るべき原理や基礎となる技能について、幅広い知識を総合的に評価しています。

基本情報技術者試験 [ Fundamental Information Technology Engineer Examination ]
対象者像:高度IT人材となるために必要な基本的知識・技能をもち、
              実践的な活用能力を身に付けた者

ということでプログラマなら取っておかなければならない資格のような気がします。
対策本を読んで過去問を解けばできないことはなさそうですが、
しっかりとした理解なしに資格を取得しても価値がないと思うので
こういう本を読みながら基礎知識を蓄えているところです。

以下は役に立ちそうなリンクなど。
情報処理推進機構：情報処理技術者試験

	午前	午後
試験時間	9:30～12:00(150分)	13:00～15:30(150分)
出題形式	多肢選択式（四肢択一）	多肢選択式
出題数 解答数	出題数：80問 解答数：80問	出題数：13問 解答数：7問

情報処理推進機構：情報処理技術者試験：試験要綱・シラバス・過去問題 など
[Web問題集] 基本情報技術者／応用情報技術者／ITパスポート - 気軽に資格学習 [無料]

[書評]コンピュータはなぜ動くのか～知っておきたいハードウエア＆ソフトウエアの基礎知識～

コンピュータはなぜ動くのか～知っておきたいハードウエア＆ソフトウエアの基礎知識～
矢沢 久雄,日経ソフトウエア
日経BP社
発売日：2003-06-02

ブクログでレビューを見る»
プログラマになるなら知っておくべき基礎知識を広く浅く説明した本です。
プログラマになりたい大学生などにはオススメでしょう。
新人研修の内容が理解出来ない場合にちょうどいいレベルかも。

ITパスポートや基本情報技術者などの資格を取る前に読んでおけば
試験対策本を丸暗記、みたいにならなくて済むかと思います。
次の記事で紹介するプログラムはなぜ動くのかも読んでおくと良いでしょう。

それでは。

[書評]良いコードを書く技術 読みやすく保守しやすいプログラミング作法

良いコードを書く技術　－読みやすく保守しやすいプログラミング作法
縣 俊貴
技術評論社
発売日：2011-04-09

ブクログでレビューを見る»
良いコードを書くためのHow-to本です。
とっつきやすく読みやすいため2時間ほどあれば読み切れます。
本書P.15-16に書かれていることがこの本に対する全てです。
本書で基礎を理解したら原典と呼ばれる良書を読みましょう。
幸い、本書の付録には解説付きの参考文献が載っているので
次に読むべき本について戸惑うことはないでしょう。

色々なレビューにあるように「内容が薄い」と感じられるのは、
もう既にある程度良いコードを書けているから
期待に沿うような目新しい技術に出会わなかったからなのでしょう。

悪い本ではないのですが過度の期待を持たせすぎて
Amazonでは低い評価になっていますね。

「普通のプログラマになりたいひよっこプログラマのためのステップアップガイド」と
帯の文章を変えればちょうどいいかもしれません。
大学の情報科1年とかIT系専門学校の生徒が読めば得るものは多いでしょう。きっと。

参考文献がわかりやすく解説付きで載っているのでそちらを読むべきです。
どの本も原典と呼ばれるような良書なので深い理解が得られるでしょう。
一部抜粋して以下にリンクを貼っておきます。

それでは。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

Code Craft ~エクセレントなコードを書くための実践的技法~

Code Complete第2版〈上〉―完全なプログラミングを目指して