Clean ArchitectureとHanamiですっきりしてきた
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
チームを自己組織化を促進するための「境界」の引き方 - TechとPoemeの間
最近，チームを自己組織化させるためにどうするかみたいなことをよく話したり考えたりするのだけれど，チームの自己組織化を考えるうえで，特に組織の「境界」をどこに引くかはとても重要なんじゃないかなあと思うので，今の考えをまとめておく． 基本的にはどのような組織にも当てはまる話ではあるが，主にソフトウェアシステム開発の現場での経験が元になっていることをご理解いただきたい． 自己組織化とは何か いろんな定義があると思うのだけど，自分は Scrum Alliance の認定スクラムマスター研修にて日本人唯一 *1 の認定スクラムトレーナーである江端一将さんが仰っていた定義がわかりやすいと思う． 1. チームのゴールが明確であること 2. チームの仕事や裁量の境界が明確であること 3. チームメンバーが，自分たちのやるべきことを自分たちで 0.1 秒以内に決定できること また，最近同僚と話していた中で出
Ruby on Rails の魅力と思想 - ボクココ
ども、@kimihom です。 私は Web フレームワークは Ruby on Rails を利用している。かれこれバージョン2.2 の頃から使い続けているので 7年以上になる。そこまでして私が Ruby on Rails を使い続ける魅力について個人的な想いを記していく。 Rails の作者 DHH と彼の環境 Rails の作者として有名な DHH(David Heinemeier Hansson) という名前は、 Ruby on Rails を触ったことがあるなら必ずや聞いたことがあるだろう。しかし、彼のいる会社 Basecamp がどんな想いでどんなことをしているかを知っている人は案外少ない。 Basecamp はプロジェクト管理の SaaS である。今や世界中に顧客を抱える超有名サービスであり、Basecamp は Ruby on Rails の最新版をプロダクトに反映され続けて
逆算方式による詰将棋の問題生成プログラム - すぎゃーんメモ
将棋を始めた ので、詰将棋を毎日のように解いているのだけど、せっかくなら詰将棋の問題を自動生成してみたい、と思って試してみた。 前提知識 詰将棋とはどんなものか 攻め方（先手）が玉方（後手）の玉を詰ますのが目的。 攻め方は必ず王手をかける（玉方は必ず王手をはずす）。 玉方は盤上と攻め方の持駒以外すべての駒（ただし玉は除く）を合駒として使用できる。 玉方は最善を尽くし、最も長く手数がかかるように逃げる。 玉方は無駄な合駒をしない。 その他は指し将棋のルール通り。二歩、打ち歩詰め、行き所のない駒、連続王手の千日手はいけない。 (日本将棋連盟の詰将棋ページより) 手法 コンピュータによる詰将棋の解答・問題生成というのは20年くらい前から既に様々な論文などで研究されているようだ。生成については、主に「ランダム法」「逆算法」といった方式があるらしい。 あまり論文にちゃんと目を通して調べてはいないけど
ライブラリの守備範囲は狭い方がいい - Konifar's WIP
開発で使うライブラリってどう選定してますか？ たぶん選定基準は様々ですよね。社内で基準が明文化されてるところもあるかもしれません。 選定の際には、GitHubスターの数やドキュメントの充実度、最終更新日といった客観的な指標はもちろん、キャッチアップコストやサービスの規模といった開発上の様々なトレードオフを考慮する必要があります。自分は漠然と「ライブラリはあんまり大きくない方がいいなぁ」と考えていたんですが、ちゃんと思考整理できていなかったので、ざっとまとめておこうと思います。 Android開発が多いので、Androidのライブラリを例に話します。あくまで現在の自分の考えのまとめなので、それ違うんじゃない？と思われるところもあるかもしれませんが、その辺は優しくツッコミいただけると嬉しいです。 ライブラリはみんなの課題を解決する そもそもなぜライブラリを使うかというと、その方が楽だからですね
コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
初めての新規サービス開発を通して学んでいること - クックパッド開発者ブログ
こんにちは。投稿推進部の清水(@pachirel)です。 2009年にクックパッドに入社してから、インフラ周り、クックパッドの人事周り（採用・評価）や広告周りのシステム開発を担当していました。 2014年4月頃から、2〜3名の小さなチームで新規サービスのプロトタイピングをいくつか行っています。 企画の詳細は省きますが、私がこの10ヶ月ほどで学んだことをまとめました。アジャイル開発やLean startupの考えに共感しているので、そこから得た内容に私の体験を付け加えたものになっています。 今回はプログラミングに関する技術的な内容は含まれていません。 なぜ作るか スタートアップが失敗する原因で一番多いのは「人が必要としていないものを作ってしまった」というものです。 The Top 20 Reasons Startups Fail 社内の新規サービス開発でも同じ傾向があるのではないでしょうか。
現場のフォーム - steps to phantasien
このごろ仕事の進みが悪く、しかもまったくの自業自得で肩を落としている。 今日はそれをふりかえり明日への糧としたい。反省文。 仕事の進みは「遅い」だけ。動いてはいる。一歩一歩は正しい。 でも一歩を踏み出すまでが遅い。正しい一歩を踏み出せる、正しい姿勢をとるのが遅い。 背中を丸め足を引きずる。たとえばこんなふうに… Bisection ある昼下がりにバグ修正を頼まれた。リグレッション。ここ三ヶ月くらいで壊れたらしい。 リグレッションを直す「正しい」一歩目は、二分探索で原因のリビジョンを探す bisection 作業だ。 でもこのバグ、bisection が面倒そう。なんとなく原因の想像はつくからあたりをつけて直してしまおう・・・ ・・・半日たち、結局あたりはつかない。日が暮れてしょんぼり帰宅。 翌朝気を取り直し bisection をしたら 2 時間でリビジョンの特定がおわる。あらら。 しかも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
