習慣に気をつけなさい、それはいつか性格になるから。スマートフォン用の表示で見る習慣に気をつけなさい、それはいつか性格になるから。sat0yuのブログ2019-11-15システムの目的を忘れないことこれは30日チャレンジの17日目(2019/09/25)に書かれた文章ですあらゆるシステムにおいて、ユーザが入力可能な値が増えるほどシステムの複雑性が高まる。して見るとあえて文字に起こすほどのことでもないが、新規のシステムや機能を検討している段階において本主張はしばし見過ごされることがある。「そもそもこの値はユーザから入力してもらう必要があるのか」という問いを立て、What‐何を創るかを洗練させることができるエンジニアは少ないのではなかろうか。筆者はいま、来春リリースを見据えた新たなアプリケーションの開発に携わっており、本日もチームメンバーと機能の検討を行った。議論の中で、ある機能をスコープから外すと一気に設計がシンプルになるモデルが発見された。一言で説明すれば、それは時間割を表現するモデルで、機能としてはユーザごとに自らが作成した時間割にもとづく進捗管理を行う。して、時間割モデルをスコープから外すと大きく設計が簡潔になるのだろうか。10:00システムの目的を忘れないことTweetもっと読むコメントを書く2019-11-14リファクタリングをしたいエンジニアこれは30日チャレンジの16日目(2019/09/24)に書かれた文章です新規事業においては、プロダクトの方向性が変わったり、当初は想定していなかった機能が増えたり、What―何を創るのかという点の不確実性が大きい。結果として、コンポーネントの責務範囲が曖昧になることでコード全体の品質が低下する。類似のコードがそこかしこに偏在に、保守性が低く、バグの温床になりやすい。経験や知識に裏打ちされた洞察でWhatの部分想像したり、適切なデザインパターンを採用することで、不確実性に起因するコード品質の低下を防ぐ努力はできる。どれほど優れたエンジニアであってに、本質的に新規事業の未来を予見することは不可能だ。変化するビジネスに追従・先回りできるだけの柔軟性と機敏性を保つことに心血を注ぐべきだろう。一方で、「防げる」種類の問題も存在する。それはかの有名な名言「早すぎる最適化」である。これはHow―どうやって創るのかに関する不確実性と関係している。Howは定義からしてWhatに準じる概念であり、Whatが定まらない限りはHowの不確実性も収束しない。残念ながら、我々エンジニアという生き物はHowの不確実性を正しく認識できないらしい。さまざまな理由が考えられるだろう。新しいデザインパターンを試してみたい、慣習に従うと数値型よりも文字列型のほうが便利だ、現状のままでも問題はないが煩雑としたコードベースを許せないなど、可能性はいくらでもある。筆者が一番気に入っている比喩は手術好きの医者の例である。じつは一部の医者は「手術をしたい」と考えているのだそうだ。自分が患者の身になったところを想像すれば、なんて恐ろしいことかと思うだろう。「手術が好き」で医者になった人間からすれば、当然手術をしたいと考えるし、そのような診断を下したとしても違和感のない話である。同様にして、技術が好きでエンジニアになった人間が手術=リファクタリングをしたいと考えるのはごく自然なことだろう。これが認知バイアスとなって働き、Howの不確実性を正しく認識することを妨げている可能性は否定できまい。筆者が今、エンジニアとして新規事業の開発に携わっているという話はこれまでも何度か述べた。じつは数週間前から細々と取り組んでいたリファクタリングがあったのだが、本日リファクタリングを元に戻すことが決定した。主な理由は2つあった。(1)リファクタリング過程において複数の機能実装間でコードの一貫性が欠ける(2)不確実性の収束が期待できず後ほどまた別の変更が必要になる可能性が高い(1)に関しては、近々多数のエンジニアがチームにジョインすることが決まっているため、コードベースの理解を妨げる要因を避けたいという外部状況も関係している。注目すべきは(2)の理由で、まさに上で述べた議論に一致している。今回、筆者が犯してしまった失敗は、WhatとHowの両方で不確実性が高い状態のままリファクタリングを進めてしまったことである。「リファクタリングは(少なくともコードに改善する限りにおいて)良い習慣だ」という認識をもっており、不確実性の観点を十分に考慮に入れることができていなかった。本経験をとおして、プロダクト開発における不確実性の考え方を一層深めることができた。)が与えられたとき、どのような実装を考えるだろうか。時間必要なため効率的だとは言えない。本文では所属判定問題に対するひとつの解として、確率的データ構造BloomFilterをみていく。本文章で説明するBloomFilterをgolangで実装したのでコードと見比べてて読みすすめると理解が捗るかもしれない。GitHubまずはじめに、確率的データ構造とは一体何を指すのだろうか。Schema設計これは30日チャレンジの13日目(2019/09/21)に書かれた文章ですGraphQLのスキーマ設計において進化可能なデザインを実践するためにxuorig氏が記事を残している。本文はxuorig氏の記事の要約である。blog.apollographql.comGraphQLではAPIクライアント側が必要となるフィールドを明示するため、サーバー側が意図しない(突然フィールドを消すなど)限り、自然と後方互換性を保った開発ができるように設計されている。追加情報を与えることもできる。することで、スキーマ定義を通してクライアント側に古いフィールドを使い続けないよう促すことができる。それでもなお、後方互換性を保ちながら開発を進めていくことは難しい。xuorig氏の記事では、例を交えながら3つのTipsが提案されている。Schema設計Tweetもっと読むコメントを書く2019-11-11読み書き禁止ファイルを変更できてしまう謎これは30日チャレンジの9日目(2019/09/17)に書かれた文章ですLinuxで開発したことがあるエンジニアならpasswdコマンドを知っているだろう。コマンド名が示すとおり、ログインパスワードを変更するコマンドだ。パスワードを記したファイルは一体どこにあるのだろうか。これも知ってるエンジニアは多いだろう。ユーザー名、(暗号化された)パスワード、ログインシェルなどログイン時に必要な情報が一行ごとに保存されている。最近のLinuxディストリビューションでは、もはやパスワードは/etc/passwdに保存せずに/etc/shadowに移すことで安全性を高めているようだ。上記ファイルが一般ユーザから不要に読み書きされるようなことがあってはならない。/etc/shadowに至っては一般ユーザは読み込みさえ禁止されている。/etc/shadowしかしここでひとつ疑問が浮かんでくる。読み込みできないはずの/etc/shadowがどうして一般ユーザが実行したpasswdコマンド(/usr/bin/passwd)によって変更されるのだろうか。一般に、ユーザが実行したプロセスは実行ユーザの権限をもってファイル読み書きを行う。したがって、例えば読み込み権限のないファイルを表示しようとしても当然エラーが発生する。それにもかかわらずpasswdコマンドで/etc/shadowの書き換えが可能なのだとしたら、なにか全く別の機構が隠れているのかもしれない。deniedじつはこの隠れた機構こそが、本文を書くに至った今日の学びである。(SUID)」と呼ばれる機構だ。SUIDは読み/書き/実行と並ぶ特殊なアクセス権である。このアクセス権をもつ実行ファイルは、実行ユーザではなく所有ユーザのアクセス権限で処理を行う。我々がpasswdで抱えていた疑問に対する回答となる。実際にpasswdコマンドのアクセス権限を確認してみると、通常は実行権限「x」が埋まる箇所(passwdコマンドの所有者権限)には代わりに「s」が記されている。/usr/bin/passwdSUIDはpasswdコマンドが代表格としてあげられるが、その他にもWebサーバーのような常時稼働する実行形式にも利用されることがある。「起動時にポート80をListenするにはrootが必要だが、一度起動してしまえば権限を降格しても構わない」といったユースケースにも有用なのだ。ちなみにSUIDは下記コマンドで設定することができる。頻繁に使うことはないかもしれないが、知識として持っておくと便利だろう。fileちなみに、本文を書くきっかけとなった今日の学びは「詳解UNIXプログラミング」から得た。Webエンジニアとして普段からアプリケーションコードを書いていると、自ずと学びの範囲が狭まってきてしまう。「詳解UNIXプログラミング」のような色褪せない名著は、知識の外縁を広げて新しい学びを得るための格好の材料となるだろう。Hashingこれは30日チャレンジの6日目(2019/09/14)に書かれた文章です「あいまい検索」と聞いて何を思い浮かべるだろうか。Googleもあいまい検索機能を提供している。試しに「あいまい検索」と検索してみてほしい。「曖昧検索」にヒットしたページも結果に表示されるだろう。Hashingをみていきたい。HashingTweetもっと読むコメントを書く2019-10-28RDBにおける木構造の表現方法これは30日チャレンジの3日目(2019/09/11)に書かれた文章です我々が住む世界には木構造をもつ事象が多く見られる。住所は根(国)から節(県)に分かれ、やがて葉(番地)に到達する木構造として表現できる。このような木構造を伴う情報を永続化してアプリケーションで取り扱う場合、どういった選択肢が考えられるだろうか。本文ではとくに、現在最も広く用いられているリレーショナルデータベース(以下RDB)において木構造を表現する方法として以下の3つを紹介する。月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。