ども、@kimihom です。 とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。 結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。 サービス設計レベルでの"美しさ" を極めよう いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。 その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が１冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われて

Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる

本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、

ども、@kimihom です。 最近は SaaS サービスもどんどん増えてきて、決済手段としてクレジットカードを選択する場合が多くなってきた。SaaS サービスであれば、月額課金モデルというところがベースになってくるので、実際に運用している側から検討した方がいいことをまとめてみようと思う。 顧客の 5% は決済に失敗すると覚悟せよ まずコレ。この記事で一番言いたいことでもある。意外とクレカの利用制限を超えてしまっていたり、有効期限が切れていたりなどして毎回顧客の 5 % くらいは月額決済に失敗する。その時の対策をあらかじめ考えておく必要がある。決済に失敗したらその翌月は一切使えないようにするってのは、意図せずにクレカ失敗した顧客に対してあまりに可哀想なので、そこで "決済してないけど使える状態" という一時的に矛盾した状態が発生することがよく起こる。 この問題に対応するには、いくつかの方法

CSSは設計手法も大事ですが、どういう単語で名前をつけていくかも大事だと思っています。 個人個人でばらつきが出るところでもありますし、「単語名 英語」で検索をして探した単語を使ったけど若干意味合いが違ったといったこともあると思います。 クラス名を決めるためのリストを見かけることもありますが、英単語の読みは書かれていても意味合いが書かれていることは少ないように思います。 自分の確認用と、チームで製作するさいの基準になるようなものを作りたいと思い、単語とその意味を短くまとめてGitHubにあげています。 CSS クラス名リスト | GitHub 以下投稿時の内容です。 名前をつけることは難しいですが、とても重要なことです。 CSSには設計思想が必要ですが、実践するにあたり、名前と機能の意味がとおり、名前のつけ方にブレがないようにするべきです。 このドキュメントでは、CSSでよく使われる単語を分

記載されている内容は2016年12月03日時点のものです。現在の情報と異なる可能性がありますので、ご了承ください。 また、記事に記載されている情報は自己責任でご活用いただき、本記事の内容に関する事項については、専門家等に相談するようにしてください。 今回は、そんなSwiftを今の内に学習しておきたい！という方に向けて、無料で利用できる入門・初心者向けの学習サービスをご紹介していきます。Swiftが第一線で活躍する言語になるかもしれない未来に備えて、この機会にぜひ、Swiftに入門してみてはいかがでしょうか？

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

まずFluxとはなんだろうか。Fluxの解説はすでに多数掲載されているが、ここでは「データフローを一方向としたアーキテクチャ」と定義したい。 そもそも、FluxというのはObserverパターンにちょっとした規則を設けて、かっこいい名前を与えたに過ぎないのだが、現代のフロントエンドはこのFluxを見事に受け容れた。なぜか。それは開発者が秩序を求めたからである。 これは、拡大し続けるフロントエンド・サイドの開発規模に対して、従来のMVC、正確には複数のViewと複数のControllerが相互にデータを受け渡し合うアーキテクチャがスケールしなくなったことに起因する。（ここではMVCを厳密に定義していない。GUIアーキテクチャについてなのかバックエンド・アーキテクチャについてなのか判然とさせないまま、俗語的に用いている） シングルトンという名でごまかした巨大なグローバル神オブジェクトを至る所で

技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

プログラミングでよく使う英単語のまとめ【随時更新】 随時追加、整理していきます。 名前をつけるときには、名詞、動詞の違い、複数形、過去形などに注意しましょう。 オブジェクト指向では、クラス名は名詞、メソッドは動詞とします。 使ってはいけない言葉 get / set アクセサ (getter / setter) やプロパティによく使われている。 それ以外に使うと混乱を招くのでよくない。 get は軽量な処理と考えるので、中に重い処理は書いてはいけない。 単純な取得/設定以外で使いたくなったら他の言葉を考える。 load, save, commit, store, enable, disable, fetch, register, configure, add, etc... check 意味が広すぎて何をしているかわからない。 できるだけ別の言葉を使う。 具体的に何をしているかに分解して考え

たくさんいいねいただきありがとうございます。2016年の記事で古いのでいずれ全面改訂しようと思いますが、古さが目立つ箇所のみまずは訂正しました。 データ分析・機械学習の代表的な手法には何があるか 代表的な本、技術リスト、データサイエンティストの推奨ではデータ分析・機械学習手法はどんなものがリストアップされているか ここでは、統計学的検定、多変量解析、機械学習を分けていない 構造化データ（いわゆるテーブルデータ）のみ対象とし、画像、自然言語処理、マーケティングの専門的な分析等は対象外 補足を下記に 代表的な手法と紹介のされ具合 分析手法 『Rによるデータサイエンス-データ解析の基礎から最新手法まで』 『はじめてのパターン認識』 データサイエンティスト協会スキルチェックリスト 「デジタルガレージCDOから学ぶ！マーケターのための実践・データ分析入門～事例紹介を通じて5つの手法をマスター～」 デ

GithubのPRや海外Slackチャンネルでチャット、はたまた英語圏のエンジニアとやりとりする等、英語で文章を書くことはしばしばあります。そんな時、自分がよく使っている方法について書きます。 先に一番大事なこと 大事なことは、英語はあくまでもツールだということです。伝えたい内容が重要であり、英文を書くことに時間かけることはエンジニアにとって不毛です。 よっぽど英語が得意な人でないかぎり、一から英作文すると時間がかかって本質的でないところで時間を消費するということです。 なので一から文章を考えるのでなく、なるべく"型"を知ることがポイントだと考えています。それを踏まえた上で御覧ください。 文章を書く アルクの英辞郎とGoogle, Githubを組み合わせる 恐らく多くの人がGoogle翻訳などを使って英文を作っているかと思うのですが、アルクの英辞郎と組み合わせるともっとはかどります。理由

ども、@kimihom です。 今回 Github を中心とした OSS 界隈で有名になるいくつかの方法やメリットを挙げようと思う。私自身はまだまだ未熟者で、できていない部分もあるので、参考程度に読んでいただけたら幸いである。 OSS 界隈で有名になること OSS界隈で有名になるとは具体的にどんなことかっていうと、「誰もが使っているライブラリを作った人」になるというのが端的な説明である。Ruby on Rails を作った DHH といったように、人気のOSS であればあるほどエンジニア界隈では知らない人はいないくらいなレベルに到達することができる。やがてそれに関しての勉強会やカンファレンスが開かれたりするようなレベルにまで達することもある。ギークなエンジニアの方々であれば憧れの一つとなるだろう。 んで、そうなるとどんな良いことが起こるかっていうと、自分が目指したソフトウェアを他の皆と作り

最近、Amazonのエンジニア採用担当者から連絡を受けました。Amazonは、ベルリンオフィスのチームのソフトウェアエンジニアの採用面接をしていたのです。 連絡を受けてから契約書にサインするまでのプロセス全体は、2カ月でした。採用プロセスで経験したことと、私が合格できた理由として思い当たることをお知らせしたいと思います。 この記事で、もし私が何か重要なことに触れ忘れていたら、ぜひコメント欄に書いてください。出来る限りの詳細を回答に書きます。 4月27日：最初の連絡 採用担当者からの連絡は、 LinkedIn 経由でした。ベルリンオフィスのチームのソフトウェアエンジニアを募集しているので、もし興味があれば、最新のレジュメを送って欲しいとのことでした。私は、常にレジュメを最新にしていたので、翌日、Eメールに添付して送りました。 彼女からの返信には、募集しているソフトウェアエンジニアの役割と面接

言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

We asked all learners to give feedback on our instructors based on the quality of their teaching style.