サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今年の「かわいい」
izumisy.work
実際の現場に現れる負債とかクソコードとか呼ばれるものは、簡単にできるはずのものが何十にも不要な複雑性でラップされた成果物(標準ライブラリの実装を自前で全部書いていて、かつエッジケースでバグだらけ、とか)であることが多い。しかし一方で、そもそもの実現したいこと・あるべき仕様のレベルである程度複雑性が仕方ないケースに対して、最短ルートで立ち向かったものが技術的負債扱いになってしまうこともある。 かつて、某データフォーマットプロトコルで外部のアイデンティティプロバイダとデータ連携を行う機能を開発したことがあった。 さすがに1からRFCに沿って自分で全部作るのはおかしいに決まっているので、Githubで使えそうなOSSライブラリを探していたのだが、その際に見つけたものは90%は欲しい機能があるものの残り10%ほど必要な機能が足りていなかった。そこまで使えるなら、あとは自分らでフォークして足りない機
open.spotify.com Podcastで聴いて面白かったので、Wikipediaに書かれていない話だけ備忘録的にメモ。 インキュベータ時代 UCバークレーのルームメイトの親戚がインキュベータを始めるため、起業したい若者を探していた。その話に乗っかりシリコンバレーで起業。最初期はマッチングアプリをやったりFlashでマルチプレイヤーのunoを作ったりした。 同時期にスティーブ・ジョブズがAppStoreを発表。それを見て「これは絶対来る」と確信し、作っていたものを全部畳んでゲームアプリ開発に全振り。2008年頃。今ではよくあるRPG風味のパズルゲーを作ってたくさんのユーザーを獲得した。 マネタイズの方法は考えてなかった。 OpenFaint時代 自分たちがゲーム開発で用いていたリーダーボードやチャットルームなどのソーシャル機能を汎化してプラットフォーム化するアイデアを思いつく。 簡
転職活動でいろんな会社のエンジニアの人と話して思ったことをマイクロサービスの観点で備忘録がてらメモしておく。 よくあるマイクロサービスの分割軸として、業務機能、ユースケース(動詞)、リソース(名詞)あたりが一般的だが、これらどれもがドメインを構成する要素であるため、マイクロサービスに分割してしまうと結果的にソフトウェアの形がビジネスルールの変化を制限してしまうケースの方が多い気がしていた。実際、規模の小さい開発組織でマイクロサービスやってみました〜からのツラミはそういうのが多いイメージで、よくある「マイクロサービスやったけど逆に開発遅くなった」みたいなとこは上で挙げたような粒度の切り方をしている印象がある。 この件に関して、去年末の転職活動のタイミングでいろいろな人に話聞いてみた結果、実際にマイクロサービスでうまくやっていそうな組織は、上で書いたようなドメインを構成する要素でマイクロサービ
前職でフロントエンドチームのスペシャリストとして開発プロセスを考えるポジションにいた。そのときに試してみて良かったなと思えたのはAutoApproveという仕組みで、これは任意のPRにAutoApproveというラベルが付くとGithub Actions経由でPRがGithub BotにApproveされコードレビューなしでマージできるというもの。 コードレビューでは、プロダクトの規模が大きくなっていくにつれ認知的・時間的なコストが嵩む。レビュワーも広汎なドメインや設計レベルの知識が求められたり、人が増えると「これレビューする意味ある?」みたいなPRもレビュワーにバンバン飛んでくる。そうなると、全体的にさらっと見てApproveしたりする。これはもちろんレビューをされる側もそうで、コードレビューという仕組みがあるとなんとなくレビューをゲートキーピング的に捉えてしまいがちなところがある。 な
インターネットで調べたところ、どうやらUbuntuがサポートするrtl8192cuというチップとして認識させれば動くとのこと。 エレコム Wi-Fi 無線LAN 子機 300Mbps 11n/g/b 2.4GHz専用 USB2.0 コンパクトモデル ブラック WDC-300SU2SBK 発売日: 2014/05/11メディア: Personal Computers というわけで、rtl8192cuのモジュールをmodprobeでロードし、lsusbで分かったベンダIDとプロダクトIDをカーネルに認識させる。 $ sudo modprobe rtl8192cu $ echo "056E 4009" | sudo tee /sys/bus/usb/drivers/rtl8192cu/new_id こんな感じで、対象となるモジュール名の配下に置かれている new_id ファイルへデバイスの情報を
izumisy.work マネージャという役職として働くようになってそろそろ2年目が見えてきた。 自分の所属するUniposでは、複数チームが開発組織に並存するようになってから日が浅く(とは言っても1年以上は経っているが)それにともなって各チームをマネジメントするミドルマネージャ(中間管理職)というポジションはまだ黎明期的な立ち位置にある。転職組はある程度経験者もいるとはいえ基本的にはみんながニューゲーム状態であり、自分も全くと言っていいほど手探りな進み方をしている。 そんな中でも、ある程度「ミドルマネージャかくあるべし」を知るのに役立った書籍を3つ紹介する。 HIGH OUTPUT MANAGEMENT マネージャという立ち位置ならこれを読まない人はいないレベルのやつ。 なにから読むべきか... というときにはまずこれで間違いない。とはいえ、文章もなかなか小難しい感じでもありかつボリュー
【これはUnipos Advent Calendar 2021の2日目の記事です】 つい最近、EarthlyというDockerコンテナベースのビルドツールで、自分の開発しているGoのアプリケーションのMakefile/Dockerfile/docker-compose.yamlを置き換えたのでそれを記事にしてみる。 Earthlyとは github.com めちゃくちゃ雑に言うとDockerイメージをベースにしたビルドツール。 できることとしてはGoogleが作っているBazelに近い*1が、書き味はMakefile+Dockerfileに近く*2、独特の文法が少ない雰囲気。当然、言語やフレームワークに依存しない。まるでローカル環境でビルドをしているかのようにシームレスにコンテナ環境でビルドを実行できる。 Earthlyは書き味こそDockerfileと似ているが、Dockerイメージを作
discourse.elm-lang.org つい先日、数か月ぶりにElmのupdate話がでてきた。 Elmは0.19からほとんどメジャーバージョンアップしていない。最後のリリースは約9か月前にもなる。 この事実だけを知ると「Elmはもう終わったのか」「Evan*1は開発のモチベーションを失ったのか」と思われることがある。実際そういう話はネットでチラホラ見かける。確かに、フロントエンド開発言語のAltJSとして近しいTypeScriptやFlutterと比較すると、あまりにも機能追加され無さすぎるようにも見える。究極的には「何と比較するか?」という話だとは思うが、たしかにフロントエンド界隈的な観点ではElmは亀の歩みなのは間違いない。 変化するのはいいことだ... なんとなく肌で感じる人も多い事実として、世の中には"最先端を目指して変化するのはいいことだ"という暗黙的な統一見解が存在して
うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。 そうだよなぁ。システムの寿命よりビジネスの寿命のほうが短くなってるのかも— ボム / SIer (@bombombomb2017) 2021年8月29日 これにめちゃくちゃ共感した。 よくあるアーキテクチャ設計では、ドメイン層と応用層を分離することで応用層におけるコントロール不能な変化をドメイン層に及ばないようにさせたりする。しかし、現実のプロダクト開発ではDBやフレームワークなどの応用層で起きる変化よりもドメイン層の変化のほうが圧倒的に多い。システムにおけるすべての中心にあり、あらゆるところから依存されているドメインが頻繁に変化するとなると非常にツライ。 とはいえ、ビジネス・アーキテ
後学のために自分の考えていることをまとめてみる。 考えられるパターン これまでの経験から以下4つのパターンがある。 ローカルStateでprop-drillingする ローカルStateかつイベント経由でデータ交換をする グローバルStoreとローカルStateを併用する グローバルStoreのみを使用する 1. ローカルStateでprop-drillingする propとしてコンポーネント間のデータをやりとりする手法。 ほぼすべてのUIコンポーネントを親からデータを受け取りDOMを出力するだけの純粋な関数として表現できるため、全体の設計自体はシンプルになる。手間は多いが魔法は少ない。 コンポーネントの粒度が小さいアプリケーションの場合にはいわゆるバケツリレーと揶揄されるデータの受け渡しが頻発し、これに嫌悪感を持つエンジニアもいる。 2. ローカルStateかつイベント経由でデータ交換を
以下をやるだけ # インストール&初期セットアップ $ brew install rustup rust-analyzer $ rustup-init $ rustup update # プロジェクト作成 $ mkdir your_own_rust_project $ cd your_own_rust_project $ cargo init --vcs git --bin # rust-analyzerを使わないならrlsと関連コンポーネントをインストールする $ rustup component add rls rust-analysis rust-src Rustの環境を構築するには brew install rust ではなく rustup のほうをインストールするのが正解っぽい。インストール後に rustup-init で初期化するとコンパイルに必要なrustcとかもインストール
この記事はElm Advent Calendar 2020の8日目の記事です 今年の春頃からコツコツと個人開発のアプリケーションで使うためのElm用Firestoreライブラリのパッケージを作っていたので、その紹介をします。 github.com できることはREADMEに書いてあるとおりで、基本的なCRUDオペレーションが一通りサポートされているのと、たぶんトランザクションもかけられます。 また、このelm-firestoreは独自のエンコーダ/デコーダをパッケージのモジュールとして提供しており、Firestoreとの通信で使用される特別なJSONのデータ構造をパッケージの利用者が意識しなくてもよい作りになっています。 READMEにおいて "A type-safe Firestore integration for Elm." と謳っているのは、JSを書かずにFirestoreとの連携
いろいろやってみた知見が溜まったのでまとめ。 開発 時間給で労働を売る古き良きスタイルの副業。副業として機能開発とかバグ修正とかやったりする。 自分はUIがいい感じだったからという理由でOffersを使って副業を探した。 offers.jp 注意点として、日中まともに会社員やっている人だと、稼働時間が自ずと平日夜か土日だけになってしまう。これが厳しいところとして、副業先のチームの開発プロセスには載ることが基本できないため、非同期作業みたいな形になる&開発スピードが求められるコアな機能開発みたいなアイテムには入りづらくなる。 あと純粋にモチベーション的に平日夜とか仕事したくないときもある。でも副業でアサインされてると仕事しないといけない。場合によってはチームの開発作業の進捗妨害をすることにもなったりする。 独立して作業可能なアイテムを貰えるプロジェクトか、例外的に日中もコミュニケーションでき
今年の夏頃から会社で4-5人チームのリーダーをやっている。 新卒で入社したころはまさか自分がリーダー的存在になるなんて思っても見なかったが、やってみるとこれはこれでおもしろい。来年になる頃には自分がなんでこの選択をしたのか忘れてしまいそうな気がするので、ここに書き残しておく。 やってみようと思った理由 正直なところ、学生時代から「やっぱエンジニアはコード書いてナンボ」みたいな気持ちでいて、当初はリーダーだとかそういうものには微塵も興味がなかった。Twitterとかを見ていても「マネジメント層になるとコードが書けなくなる」みたいな話もちらほら目にしたり、そういうものを見ると尚更「そんなんやるもんじゃねーな...」と思っていた。 しかし、実際チームでマネジメントをしている人をみている限りでは、マネジメントをしているからコードが書けないだとかそんなことはないどころか、ビジネス的な視点とエンジニア
BtoBなソフトウェアの開発において業務知識なしにシステム設計をすることはほぼ不可能に近い。 これまで、業務支援系のシステム開発はSIer企業たちのお家芸であったが、近年ではWeb系のベンチャー企業やスタートアップであってもこれまでSIerが担っていたようなドメイン領域で戦うことが増えている。 「会計処理」「流通管理」「在庫管理」「人事管理」あたりのドメインにまつわるシステム設計は、BtoBをやっていればいつか必ず遭遇することになる。その際にドメインに関する知識を一切持たずにまともなシステム設計をすることはたいていの場合難しい。 Web系であれなんであれ、BtoBなソフトウェアエンジニアは自分たちが取り組むドメインに関する知識を持ってシステム設計に臨む必要がある。これはデザインパターンや設計手法"以前"の話だ。 ITエンジニアのための「業務知識」がわかる本 ITエンジニアのための【業務知識
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの?」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
元ネタはこれ scotthurff.com Webアプリケーションを作ったことがある人ならわかる話だが、アプリケーションは確実に予想外の状況に晒される。サーバーはレスポンスを返すのに時間がかかるし、ユーザーの環境がメモリ1G以下のこともあれば、完全に想定外の使いかたをするユーザーもいる。デザイナはそれらの現実に起こりうる可能性を全て考慮に入れてデザインをする必要がある。 2004年にBasecamp(当時は37signals)はThe Three State Solutionという提案をしていて、その内容は「全ての画面設計は3つのステート(Regular, Blank, Error)を考慮するべきだ」というものだった。その当時はまだAjax黎明期だったし、もちろんスマートフォンも存在していなかった。けれども、新しいテクノロジーが生まれるにつれて、インターネットを利用する環境は恐ろしく多様に
今年の頭くらいに書いた今年の抱負に関する記事の中で「不動産投資に関する本を読む」とあるが、ちゃんと有言実行ということでとりあえずいろんな本を読んでみたので、その感想を記事にしておく。 izumisy-tech.hatenablog.com 胡散臭い投資代表「不動産」 我々パンピーからすれば、不動産といえば胡散臭い投資ナンバーワンであると言ってもよい。 周りに「不動産投資やってますか?」と聞いてもやっている人が自分の周りにはほとんどいない。一方で「知り合いに不動産投資をしている奴がいて、全然儲からないらしい」とか「前職の知り合いで不動産投資で大失敗こいた人がいる」みたいな情報は多い。つまり失敗している人の情報はいくらか流れてくる。 不動産とインターネットの相性は最悪 不動産に限らず単価の高い情報というのはインターネットがゴミの山になりやすい、かつ情報が雑多でまとまりがないものになりがちだと思
ソフトウェア開発最大の難所と呼ばれる見積もり。見積もりに関する古典があるくらいにはやはり見積もりというのは難しい。 自分もずっと見積もりを正しくするためにはどうすることがベストなのか、ということにずっと悩みを抱えていたが、社会人2年目ももう少しで終わろうかという、ここ最近ようやく自分の中でのパターンに気がついてきた。自分が見積もりを失敗してしまう理由には大きく分けてふたつあり、それは「1日の作業可能時間を見誤っている」 と「所要工数の変更を追跡できていない」のふたつであった。 1日作業は8時間相当ではない 第一に、自分は1日の作業時間が8時間まるまるあると思い込んでいた。改めて考えてみるとめちゃくちゃな話だが、1年目の自分は「見積もりをしましょう」というタイミングになると、1日8時間を基準に何人日自分の作業量では必要になるかを起算していた。しかし、まともな社会人になればすぐに分かることだが
スマートドラッグと聞くとなんか危なそうで飲むとバキバキにキマるようなものを想像しがちだが、実態は単なる身体にいい成分が含まれたカプセルだったりする。今年くらいから、海外の健康食品系ECサイトであるiHerbでちょこちょこいろんなものを買って試し始めた。 いつだか忘れたが、AV男優のしみけんがブログで「iHerb使い始めました!」と紹介していたこともあり、少しづつトレーニー界隈では日本でも有名になってきているようだ。けれども、必ずしも筋トレに関する商品だけを取り扱っている、というわけではなく、この記事で紹介するようないわゆる軽いスマドラに該当するようなものも販売しているのでおもしろい。 L-テアニン テアニンは日本人にはお馴染みのあの緑茶に含まれるやつで、有名な文句としては「飲むとストレスを軽減できるよ」などと言われるもの。実態は単なるアミノ酸の一種で、自分は大体寝る前に飲んでいる。とはいえ
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
先日、新卒で入ったエンジニアが 「Immutable.jsの研修課題をやってるんですけど、正直なんで必要なのか分かんないっす」 と言っていた。 たしかに React, Redux と Immutable.js をセットでつかおうみたいなノリの記事はネットでよく見るが、じゃあなんでそのセットなの?という点に関してはあまり詳しく書かれていないことのが多い気がしたので、個人的にその理由っぽいのを雑に書き残しておこうと思う。 イミュータビリティのいいとこ コーディング・バグを減らす 言語仕様上ミュータブルな JavaScript は、大勢で開発してるとこっそりどこかで参照を持ったオブジェクトを書き換えてた、なんてことになりやすい。なのでデータを更新する際にはイミュータブルであることが保証できるとバグが起こりにくいコードを書ける メモリ効率がいい イミュータブルなオブジェクトは中身が同じなのでコピー
弊社では「筋肉の人」*1として知られるRichard FeldmanはElmの創造神ことEvan擁するNoRedInkに所属するエンジニア。 Evanが比較的キーノート的なElmの未来やらビジョンを語るトークをする一方で、RichardはどちらかといえばElmをプロダクションで使うにあたって、どのように書くことでスケーラブルにできるか、のようなはなしをメインに据えている感じがある。 彼はアメリカで開催されているelm-confや、ヨーロッパのelm Europeなどで割と長尺のトークを務めることが多く、その内容もElm中上級者になるにはうってつけの内容ばかり。どのトークもElmの基礎的な文法や紹介は完全に端折られていて、Elmを使うこと前提でどのようにうまく使うかにフォーカスしている。 彼の動画は会社のElmメンの会(?)の中で一気に集中して見たことがあり、僕含めみんなにとって非常に学びが
2019/6/27-28にかけて開催されていた Elm Europe 2019 というカンファレンスにスピーカーとして参加した Now on: @sy_izumi recounts the journey of the biggest Elm application in Japan. pic.twitter.com/VG0NQG1Yo3— Elm Europe (@elm_europe) 2019年6月27日 このような海外カンファレンスへの参加は、だいぶ昔にサンフランシスコへ行ったとき以来だし、とくにスピーカーとして登壇するというのは人生初だった。英語でトークをやるというのは非常に緊張する体験だったけれど、率直に言ってめちゃくちゃ楽しかった。 詳しいカンファレンスの内容などはおそらく所属している会社のブログの方で書くはずなので、こっちではもう少しパーソナルなことを書こうと思う。 CFP
よく新しいフレームワークを学ぶにはTodoアプリを作ってみるのがよい、と言われる。実際、Todoアプリを様々なフレームワークで作ってみたサンプルをまとめたサイトもあったりする。 ところが、実際に業務で作るようなアプリケーションはTodoアプリの範疇を超えている。とくにSPAにもなると、画面遷移やWebAPI連携、大規模な状態管理などなどの条件が増えるので、Todoアプリを作っているときには考慮できていなかった大変さが出てくる。 そこで参考になるのが RealWorld example apps と呼ばれるプロジェクト 端的に言うと、TodoMVCの大規模版。 規定のスペックに沿って、様々なウェブフレームワークで作られたアプリケーションのリポジトリがリストアップされている。 スペックについて "Conduit" is a social blogging site (i.e. a Medium
先日業務で1からElmアプリケーションを作りきったのでそのときの学びをメモっておく。 1. Model / Msg / View のような分割をしない Rails などのフレームワークからきた人がやりがち。 Elm でファイル分割をするのはモジュール単位でのカプセル化をするときだけでよい。 なので基本的に1画面につき1モジュールとして、その中に Model / Msg / View / Update などを書いていく。 ここからさらにデータ構造として抽出できるものがあれば後述の Opaque Type として切り出す。 2. コンポーネント指向と混同しない Elm は React や Vue.js のようなコンポーネント指向フレームワークではない。 基本的に1画面につき1モジュールとして作る。 再利用したい画面のパーツは関数として作ればよい。 3. Opaque Type の活用 Elmに
SAMパターンというのを勉強している。 www.infoq.com この記事は少しだけはてブでバズったが、実際コレを読んだだけでは例えば実際に実装に落としたときにどういうデータ・フローになるのか、というところまでは若干理解しづらい。この記事の作者のDubrayはsam.js.orgでいろんなサンプルコードを紹介しているので、それらを参照すると若干理解が捗る。 ちなみに今のところ自分の中で整理しきれた雑なSAMのデータ・フローはこれ。 パッと見の雰囲気はFluxアーキテクチャと全く違う、という感じではない。SAMはState-Action-Modelのアクロニムで、ベースになるのもその3つの要素だ。それぞれの要素の名前はこれまでのアーキテクチャを知っている人からすると、比較的馴染みやすいものではあるかと思うが、SAMの場合はそれぞれが担う責務が若干異なる。なので、たとえばStateと聞いたと
IndieGoGoでUbuntu版をbackしていたのがとうとう届いた。Windows版は「もう届いた」「小さくて最高」みたいなツイートやブログエントリーがネット上でちらほらと散見されたのにもかかわらず、Ubuntu版は随分時間がかかっているんだなと思い若干本当に届くのか疑っていたが、とりあえず届いたのでひと安心した。 GPDのロゴが散りばめられた非常にそれっぽい梱包でなかなかどうして悪くない。 Ubuntu版も箱自体はWindows版のものとさほど変わらないようだ。若干裏側の板の貼り付けが雑だが、それもそれで味があるというものだ。それにしてもGPDのロゴはかわいい。黒い箱にゴールドという配色に高級感を感じさせようという努力を感じる。 クリスマスプレゼントをもらったこどものように箱を開封して、さっそく端末のセットアップを始める。確か公式のアップデートでは、マウスコントローラのラバーにはいく
このページを最初にブックマークしてみませんか?
『Runner in the High』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く