コードを美しく保つためのたった一つの方法 - ボクココ
ども、@kimihom です。 とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。 結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。 サービス設計レベルでの"美しさ" を極めよう いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。 その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が１冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われて
大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが**「複雑性」**である。『新人プログラマに知っておいても
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
クレジットカードを扱うサービス開発で注意すべきこと - ボクココ
ども、@kimihom です。 最近は SaaS サービスもどんどん増えてきて、決済手段としてクレジットカードを選択する場合が多くなってきた。SaaS サービスであれば、月額課金モデルというところがベースになってくるので、実際に運用している側から検討した方がいいことをまとめてみようと思う。 顧客の 5% は決済に失敗すると覚悟せよ まずコレ。この記事で一番言いたいことでもある。意外とクレカの利用制限を超えてしまっていたり、有効期限が切れていたりなどして毎回顧客の 5 % くらいは月額決済に失敗する。その時の対策をあらかじめ考えておく必要がある。決済に失敗したらその翌月は一切使えないようにするってのは、意図せずにクレカ失敗した顧客に対してあまりに可哀想なので、そこで "決済してないけど使える状態" という一時的に矛盾した状態が発生することがよく起こる。 この問題に対応するには、いくつかの方法
CSSのクラス名を決めるときに使うリストをつくりました
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? CSSは設計手法も大事ですが、どういう単語で名前をつけていくかも大事だと思っています。 個人個人でばらつきが出るところでもありますし、「単語名 英語」で検索をして探した単語を使ったけど若干意味合いが違ったといったこともあると思います。 クラス名を決めるためのリストを見かけることもありますが、英単語の読みは書かれていても意味合いが書かれていることは少ないように思います。 自分の確認用と、チームで製作するさいの基準になるようなものを作りたいと思い、単語とその意味を短くまとめてGitHubにあげています。 CSS クラス名リスト | GitH
10分で実装するFlux
10分で実装するFlux 自己紹介 azu @azu_re Web scratch, JSer.info Flux /flˈʌks/ Fluxとは Facebookが提唱したSmalltalk MVCの焼き直し CQRS(Command Query Responsibility Segregation)と類似 データが一方通行へ流れるようにするアーキテクチャ ウェブUIについてそれを適応する 今日の目的 小さなFluxの実装を作りながらFluxついて学ぶ Fluxの特徴: Unidirectional data flow 本当にデータが一方通行に流れるのかを確認する Fluxでよく見る図 登場人物 何か色々いる Action Creators, Dispatcher, Store, React Views... Dispatcher = EventEmitterと今回は考える もっと実装的
Facebook の決断：MVCはスケールしない。ならば Flux だ。
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
どうしてWaltsを開発したのか - そして昨今のFlux - Qiita
まずFluxとはなんだろうか。Fluxの解説はすでに多数掲載されているが、ここでは「データフローを一方向としたアーキテクチャ」と定義したい。 そもそも、FluxというのはObserverパターンにちょっとした規則を設けて、かっこいい名前を与えたに過ぎないのだが、現代のフロントエンドはこのFluxを見事に受け容れた。なぜか。それは開発者が秩序を求めたからである。 これは、拡大し続けるフロントエンド・サイドの開発規模に対して、従来のMVC、正確には複数のViewと複数のControllerが相互にデータを受け渡し合うアーキテクチャがスケールしなくなったことに起因する。（ここではMVCを厳密に定義していない。GUIアーキテクチャについてなのかバックエンド・アーキテクチャについてなのか判然とさせないまま、俗語的に用いている） シングルトンという名でごまかした巨大なグローバル神オブジェクトを至る所で
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
プログラミングでよく使う英単語のまとめ【随時更新】
対になる言葉 comment out / uncomment コメントにする、コメントを解除する。 comment out は into a comment の意味。 comment だけならコメントする、評するの意味になる。 add / remove 追加する、削除する。 リストなどに値を入れる場合などにも使われる。 特に、末尾に追加する場合は append、先頭に追加する場合は prepend を使う。 Add A to B で、A を B に加える。 Remove A from B で、B から A を取り除く。 start / stop 開始する、止める。名詞だと開始、停止。 静止状態から動き出す感じが start。 途中からでも使える。 バーコードや通信の符号で StartCode / StopCode という使い方をする。 begin / end 始める、終わる。 最初の一歩を
Examining The Internals Of The Rails Request/Response Cycle
Come with me on a journey through the internals of Rails, as we trace a request from the web server to the controller action method, and follow the response back again. This will give you a glimpse of how Rails works under the hood, hopefully exposing some of the “magic” of the framework. We will also get to see some of the design/architectural decisions at the core of Rails. This analysis was con
エンジニアが手早く英作文をする時はかどる Tips - tomoima525's blog
GithubのPRや海外Slackチャンネルでチャット、はたまた英語圏のエンジニアとやりとりする等、英語で文章を書くことはしばしばあります。そんな時、自分がよく使っている方法について書きます。 先に一番大事なこと 大事なことは、英語はあくまでもツールだということです。伝えたい内容が重要であり、英文を書くことに時間かけることはエンジニアにとって不毛です。 よっぽど英語が得意な人でないかぎり、一から英作文すると時間がかかって本質的でないところで時間を消費するということです。 なので一から文章を考えるのでなく、なるべく"型"を知ることがポイントだと考えています。それを踏まえた上で御覧ください。 文章を書く アルクの英辞郎とGoogle, Githubを組み合わせる 恐らく多くの人がGoogle翻訳などを使って英文を作っているかと思うのですが、アルクの英辞郎と組み合わせるともっとはかどります。理由
オープンソース界隈で有名人になる方法 - ボクココ
ども、@kimihom です。 今回 Github を中心とした OSS 界隈で有名になるいくつかの方法やメリットを挙げようと思う。私自身はまだまだ未熟者で、できていない部分もあるので、参考程度に読んでいただけたら幸いである。 OSS 界隈で有名になること OSS界隈で有名になるとは具体的にどんなことかっていうと、「誰もが使っているライブラリを作った人」になるというのが端的な説明である。Ruby on Rails を作った DHH といったように、人気のOSS であればあるほどエンジニア界隈では知らない人はいないくらいなレベルに到達することができる。やがてそれに関しての勉強会やカンファレンスが開かれたりするようなレベルにまで達することもある。ギークなエンジニアの方々であれば憧れの一つとなるだろう。 んで、そうなるとどんな良いことが起こるかっていうと、自分が目指したソフトウェアを他の皆と作り
Amazonのソフトウェアエンジニア面接 | POSTD
最近、Amazonのエンジニア採用担当者から連絡を受けました。Amazonは、ベルリンオフィスのチームのソフトウェアエンジニアの採用面接をしていたのです。 連絡を受けてから契約書にサインするまでのプロセス全体は、2カ月でした。採用プロセスで経験したことと、私が合格できた理由として思い当たることをお知らせしたいと思います。 この記事で、もし私が何か重要なことに触れ忘れていたら、ぜひコメント欄に書いてください。出来る限りの詳細を回答に書きます。 4月27日：最初の連絡 採用担当者からの連絡は、 LinkedIn 経由でした。ベルリンオフィスのチームのソフトウェアエンジニアを募集しているので、もし興味があれば、最新のレジュメを送って欲しいとのことでした。私は、常にレジュメを最新にしていたので、翌日、Eメールに添付して送りました。 彼女からの返信には、募集しているソフトウェアエンジニアの役割と面接
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
入門に最適！Swiftを学習できる無料サービス10 - エンジニアについて知るならCarearte
GitHub - azu/large-scale-javascript: 複雑なJavaScriptアプリケーションを作るために考えること
氷解！データ分析、機械学習手法ってたくさんあるけどいつどれを使えばよいのか - Qiita
【プログラマーのための数学】目次 - 機械学習のために - Qiita
Machine Learning | Coursera
