開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
リモートワークのストレス | POSTD
リモートワークのストレス ソフトウェアエンジニアリング業界では、リモートワークは大いに理にかなった働き方です。大抵はPCとインターネット接続さえあれば仕事ができるからです。よって、決まったオフィスに毎日通って働く理由は比較的少ないため、リモートワークはIT職の重要な要素になっています。最も先見的な求人市場とは決して言えないベルギーにおいてさえもです。とはいっても多くの場合、リモートワークが認められるのは週の一部のみ（おそらく週に1日か2日ぐらいが一般的）にすぎません。それにもかかわらず、リモートワークは大部分の企業で導入されるようになってきたのです。 リモートワークには多くの利点があると言われており、この働き方を過激なまでに擁護する声もよく耳にします。その多くには同意するものの、リモートワークを5年以上してきた経験から言えるのは、リモートワークにはストレスが付き物だということです。そう聞く
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD
私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。本記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える！」的な投稿ではありません。本記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注：私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、本記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報：本記事が r/p
GoogleのQUICプロトコル：TCPからUDPへWebを移行する | POSTD
QUIC（Quick UDP Internet Connections）プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 （冗談で） TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ （ネットワークパケットの往復） が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 （出典： UDPを介
AWSで避けるべき5つの間違い | POSTD
今年からAWS（Amazon Web Services）クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈：（左から）DNS、CDN、静
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
単一のAWSアカウントに潜む重大な危険 | POSTD
Amazon Webサービス（AWS）のアカウントは、AWSでビジネスを展開している人にとって非常に大事なものです。ですが、AWSアカウントをたった一つしかもっていない場合、重大なセキュリティの危険に直面することになるでしょう。何が問題なのか、そしてどうすれば解決できるのかを、この記事でご紹介したいと思います。 危険性をはらむデフォルト設定：単一のAWSアカウント 単一のAWSアカウントには、EC2仮想サーバ、S3バケット、RDSデータベースなどビジネスに必要な様々なリソースとともに、IAMユーザが含まれています。アカウントへのログイン方法は基本的に2通りあります。ユーザ名とパスワードを入力するAWS Management Console、またはCLIやSDKで用いられるAWSアクセス認証情報を使うのです。以下の図は、その仕組みを示したものです。 訳注 account「このアカウントにはI
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
POSTD | ニジボックスが運営するエンジニアに向けたキュレーションメディア