2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
この投稿は 7年 前に公開されました。いまではもう無効になった内容を含んでいるかもしれないことをご了承ください。 半年ぐらい前に購入した本をやっと読み終えたので感想文を書きます。今回読んだのはアンドルー・ペティグリー『印刷という革命』。索引抜きで500P超えの大著で、お値段税抜き4,800円です。 原題は “The Book in the Renaissance” なので、本来は『ルネッサンス時代における書物』みたいな感じですかね。おそらく、「ルネッサンスが凄い」という欧米人の常識が日本人にないので、訳出時にタイトルを買えたのでしょう。 さて、本書で取り扱われるのはグーテンベルクに代表される印刷術がルネサンス期にどのような感じだったのかについて、多くのデータを元に詳細な説明をしていくのですが、内容は大体こんな感じです。 第一部:はじまり 印刷術誕生以前の本(写本)がどうやって作られたかと、
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ15年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか?ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
音楽をやっている知人の多くが口をそろえて「美輪明宏のコンサートには一度行ったほうが良い」と言っていたので,ようしどらどらと行ってきた. 会場は日野市民会館で,久々にホールでやる形式のコンサートで落ち着いて観ることが出来て良かった.ところで最近,スタンディングはライブ感あるけど疲れるし落ち着かない感じになってきた.これは老でしょうか? 美輪明宏 T シャツでも売っていないものか,あったら1着買おうと思って物販コーナーを覗いたら衣類は一切なくて,代わりに美輪明宏著の本が大量に売られていて文化という感じだった.そしてその著書が結構売れていたので,ロックバンドも凝った T シャツ売らずに著書を売ったほうが良さそう. また,会場内に「プレゼント受付」というのがあり,そこに花や手紙などを持って行くと美輪明宏に渡されるというシステムが形成されていた.すごい. コンサートの内容としては,トーク半分・歌半分
Farnam Street Mastering the best of what other people have already figured out There are three steps to effectively taking notes while reading: At the end of each chapter write a few bullet points that summarize what you’ve read and make it personal if you can — that is, apply it to something in your life. Also, note any unanswered questions. When you’re done the book, put it down for a week. Pick
Kent Beck came up with his four rules of simple design while he was developing ExtremeProgramming in the late 1990's. I express them like this. [1] Passes the tests Reveals intention No duplication Fewest elements The rules are in priority order, so "passes the tests" takes priority over "reveals intention" The most important of the rules is "passes the tests". XP was revolutionary in how it raise
汎用系のエンジニアからRubyのエンジニアとして転職して1年。 コボラー(笑)なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。 その特徴はだいたいこの3つだ。 1.テストを甘く見ているやれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。 そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。 テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。 そもそもテストケース表を若いうちに書く習慣が無いからだ。 ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。 2.パフォーマンスを考えないRubyエンジニアはパフォーマンスを考えない。 どのメソッドがどれくらいの負荷なのか意識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く