伊藤直也氏が「Web開発は高度化している」と語る理由と、押さえておきたい3つの技術領域【2014年前半のインプットlog】 - エンジニアtype
KAIZEN platform Inc. Senior Technology Advisor 伊藤直也氏（@naoya_ito） 2002年に新卒入社したニフティでブログサービス『ココログ』の開発担当となり、一躍有名になる。その後、はてなで『はてなブックマーク』など各種サービスを立ち上げ、2010年にグリーへ入社。2012年に同社を退職して以降は、フリーランスとしてベンチャーの技術顧問などを請け負う。自身のブログ『naoyaのはてなダイアリー』が人気 「Webアプリの実装で差別化は無理」という考えが変わった 現在、KAIZEN platform Inc.をはじめ複数社の技術顧問を務めている伊藤直也氏。「普段から、アウトプットの目的なく技術の勉強をすることはほとんどない」という性分から、今年上半期は「顧問としてベストプラクティスを提供するために知っておくべき領域」にフォーカスして情報収集を
現場のフォーム - steps to phantasien
このごろ仕事の進みが悪く、しかもまったくの自業自得で肩を落としている。 今日はそれをふりかえり明日への糧としたい。反省文。 仕事の進みは「遅い」だけ。動いてはいる。一歩一歩は正しい。 でも一歩を踏み出すまでが遅い。正しい一歩を踏み出せる、正しい姿勢をとるのが遅い。 背中を丸め足を引きずる。たとえばこんなふうに… Bisection ある昼下がりにバグ修正を頼まれた。リグレッション。ここ三ヶ月くらいで壊れたらしい。 リグレッションを直す「正しい」一歩目は、二分探索で原因のリビジョンを探す bisection 作業だ。 でもこのバグ、bisection が面倒そう。なんとなく原因の想像はつくからあたりをつけて直してしまおう・・・ ・・・半日たち、結局あたりはつかない。日が暮れてしょんぼり帰宅。 翌朝気を取り直し bisection をしたら 2 時間でリビジョンの特定がおわる。あらら。 しかも
社長をやりながらでも、コードを書き続けるためにやってること - ヴェルク - IT起業の記録
先週流行ってたこの辺りの記事が面白かったので自分のスタイルを。 プログラミングの生産性を上げるには コードを書き続けるためにやってること 時間がなくて乗り遅れたけど、6日遅れで書いてみた。 すごいエンジニアな人たちが書いているので、僕はちょっと違う視点で。 小さい会社ですが社長をやっていると、営業やら総務やら経理やら他のメンバがやっているプロジェクトのマネジメントやら、コードを書く以外の仕事がバカにできないくらい色々あって時間がない。でも、やっぱりコードを書くのが好きなので、そんな中でもコードを書き続け、成長するためにやっている工夫を書いてみます。 要件を聞きながら（考えながら）DB設計とプログラムのざっくりロジックを頭のなかで書く主に受託開発でやっていること。 お客さんから要件をヒアリングしながら、同時に頭の中で大まかなDB設計とざっくりロジックを組み立ててます。 どれだけ要件をちゃんと
programming - コードを書き続けるためにやってること - Qiita
プログラミングの生産性を上げるには - Cside::Private とても面白かったのでマネしてみた。人それぞれあると思うので自分のスタイルを。 といっても、かなり不真面目なので参考にはならないと思う。 1 . README.rst を書く まず最初に何がしたいのか、どんなことをしたいのかを書く 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく そして README.rst に擬似コードを書き始める コンパイルが通る必要は無い コメントもガンガン書いていく とにかく issues とか使わず全て README.rst に書いていく 一通り出来てきたら Trello にタスクを移す 2 . 擬似コードでプロトを書く コードを書いてみないと分からない事が多いのでまずはコードを書く よく iPhone でコードを書いているのだが、オレオレ言語で書いている Erlang っぽい
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
Rubyをより良く書けるようになるための課題演習のつくりかた | mah365
実戦的なコードの書き方は、どのようにして身に付くものなのでしょうか？ 文法を覚えること？ それともオブジェクト指向言語であれば、オブジェクト指向自体を学ぶこと？ 見方を変えて、関数型のエッセンスを学ぶこと？ アンチパターン プログラミングを学ぼうとするときに、プログラミング言語自体を完璧に学ぼうとするのは、無駄ではないのですがそんなに効率的ではない気がしています。 Ruby技術者認定試験【Gold】模擬問題 例えば上記の問題集をきっちり解けるようになると、Ruby自体の振る舞いについては、はっきり分かるようになりますよね。ただ、仕様を聞いて「これを作ろう！」と思ったときに、やり方に困るのではないでしょうか。 「Rubyでプログラミングできるようになりたい」という要望は、「Rubyというプログラミング言語を学びたい」のではなく、「Rubyという生産性が高いと言われている言語を使ってプログラミ
プログラミング能力を向上させるコツは、筋トレと一緒かも？ | mah365
以前ちょっとお高いプライベート・ジムでトレーニングしていたことがあるのですが、筋力トレーニングって「あ、もうだめかも」というところからが勝負で、そこから歯をくいしばってどのぐらい行けるかが、効率よく筋力アップするコツだということを教わりました。 そういった意味では、プログラミング能力に関しても同じことが言えるのかも知れない、と最近思ったのです。 自分が最高だと思ったコードしかコミットしない 過去を振り返って、今いる会社ソニックガーデンに入社したとき、CTOであるmat_akiから、「自分が最高だと思ったコードしかコミットしないで下さいね」などと言われた記憶があります。 「えー、素早く確認してもらいたいときにそんなことこだわっていたら、スピード落ちない？」 みたいなことを言った記憶もあるのですが、 「いいえ。コードのクオリティは落とさないんです。クオリティは落とさずにスピードを上げるんです」
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
ScaleOut | Supership
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
s3pw.com