どうしてスタートアップのソフトウェア設計はいつもいつもブッ壊れてるんですかぁ？ - タオルケット体操
そんな皆さまの疑問にお答えします。 スタートアップのアーキテクチャがブッ壊れてるのってなんでェ？ 先にざっくりまとめましょう。 巷でよく言及されるのはカネ、つまりは雇用するエンジニアの能力問題を元凶とする方が多いようです。 スタートアップの内情を知っていれば金と雇用の問題がどれだけ切実であるかについて異論を唱える人はいないとおもいます。しかし僕の考えによればこれはスタートアップのソフトウェア開発が抱える問題のうちのひとつ側面にすぎません。 つまりどんなに優秀な人間をかき集めようがスタートアップのソフトウェア設計は近い将来壊れる宿命にあるということです。 スタートアップの存在意義は未来の不確実性そのもの 普通のやつらの上を行け、ではありませんが。 スタートアップ企業はうまくいくかわからない事業をやることそのものに価値があります。 「誰からみてもうまくいくに決まってる」事業で金も人材も潤沢にあ
「Reactの難しさ」を分解しよう - タオルケット体操
他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 「テンプレートエンジン」として捉えて、シンタックスを攻撃するのをやめよう ライブラリとしてのReactはとても簡単 Reactの思想を理解するのはチョットムズカシイ 環境構築が難しい JavaScriptそのものが難しい GUIが難しい jQuery時代からのパラダイムシフト フレームワーク関係者の情報量が多い SPAはとりわけ難しい まとめ ずっと感じてたもやもやを書き連ねたら長くなってしまったが、ぼんやりとReactとかなんか難しそうだしめんどくさいから新規案件だけどjQueryでやろっかなどうしよっかなーと迷っている人の指針になってくれればうれしい。 他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 出た時から延々と言われ続けているものの、やっぱり今でもjQueryとRe
TypeScriptで既存の関数の引数と返り値の型情報をコピーする方法 - タオルケット体操
TypeScriptにはType infer in ConditionalTypeという便利機能があり、それを利用すると既存の型定義から柔軟に特定の方を取り出すことができます。 そして利用頻度が高そうなものについては組み込みの型定義がいくつか存在します。 関数の型定義から引数を取り出すのは Parameters<T> で、この型引数に関数の定義を与えることでその関数の引数がTupleとして返ってきます。 ちなみに返り値は ReturnType<T> で取り出すことが出来ます。 function testFunc(a: string, b: number, c: boolean): {a: string, b: number, c: boolean} { return {a, b, c}; } type TestFuncArgs = Parameters<typeof testFunc>;
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
Flutterでそこそこ規模の大きいプロダクションアプリを作ったのでスケールする設計についてまとめる - タオルケット体操
あわせて読みたい FlutterでBLoCだChangeNotifierと振り回されて消耗するまえに - タオルケット体操 筆者のFlutterに対する印象は半年前にこのエントリーを書いたときから驚くほどに何も変わっていないので、逆にFlutterは非常に明快でわかりやすいライブラリなのかもしれないですね。 hachibeechan.hateblo.jp 筆者の主張の事前まとめ Reactの学習は実質Flutterの予習 クライアントアプリを設計するにあたってはActiveRecordパターンの再発明をしてはいけない 結局MVX RXSteamとはなんだったのか DDDの勉強をすると多くの示唆を得られる Remi wareを信じろ ちなみにここ以下で述べるActiveRecordパターンはPoEEAとRoRのものの混合があるかもしれませんが、利用すべきじゃないという点において同一なので特に
今後必要になる言語や大統一言語や学習効率についてのあれこれ - タオルケット体操
今後必要になる言語はお前がどういうキャリアパスを辿りたいかによって変わる。以上。 場所によってはCもCOBOLもまだ現役だし、パチンコの制御基板はアセンブラだ（確か）。そもそもPythonだってそろそろ30年選手の言語なわけだ。その影で消えていった言語は無数にあるが、優劣だけが原因で消えたわけではない。未来を予想できる人間はさっさと投資家にでもなったほうがいい。 「今後必要になる〜〜」系の記事が定期的に話題にのぼるが、こういう話を真に受けて「参考になるぜ…」とかおもってしまう人は非常に危うい。むしろヤーヤー野次馬したり、それを諌めるなどして火遊びをするオタクのほうが賢明な可能性もある*1。 理由は簡単で、今後何がどう必要になるかは人それぞれの選択に応じて変わる。なので、たとえば仮に件のQiita記事の内容ががまともだったとしても参考に値しない。むしろ重要なのは、今後どういうものが自分にとっ
Paizaの炎上とIT業界とセックスと緑の自転車 - タオルケット体操
Paizaといえばいつの間にか雑なSIerDisりのポジショントークで各所から顰蹙を買う炎上芸人系サービスになっていたので、後日読んだときにどれの話だよとなりかねないので念のために書いておくと、女を捕まえて調教して金を稼がせつつハレムを作るゲームが炎上した話です。ようは大悪司を水で薄めたみたいなもんでしょう*1。 そういえば某社の人事が職権を乱用して夜の面接をしていたみたいな話をゴミタブロイド誌がすっぱ抜いていたのでIT業界は実質エロゲだと言って良いでしょう。 でもPaizaって最初は割と志のあるサービスだったと記憶してるんですよね。 競プロっぽい問題を解くことがそのままエンジニアの実力の証明になるかどうかについては正直疑問がなくはないですけど、それでもある意味で現状の最適解と言えなくもないわけですし、コミュ力とかいう面接官の胸先三寸雰囲気で採用が決まるような不健全なマスの転職市場を変えた
就職浪人からのネトゲ廃人ニートだった僕が未経験からプログラマーになって圧倒的成長を実現させた108のライフハックという名の精神論 - タオルケット体操
圧倒的成長をした(要出典) そういえば僕って一日26時間くらいネトゲをしていたよなーとかふと思い出しました。そんな数年前の記憶が風化する前の忘備録で、もしかしてなんか足掻いている人の助けになれば良いなとかもちょっと思ってます。 あとこの手のエントリって何故か途中で「たまたま私には○○○の経験があったのでそれを生かして×××しました」みたいなことが書いてあって「お前どこが未経験ニートだよ！」などと切れそうになる事案が稀に良くあるわけなんですが、僕はマジの持ち弾ゼロだったのでごあんしん（？）ください。 結論からいうと、ライフハックとかいってないでとにかくやりまくるしかないっぽいです。効率厨のやることが地道で泥臭いのはリアルもネトゲも同じなんだな？ 1. ネトゲをすっぱり辞めようとか考えないこと 当たり前なんですけども、リアルを生贄に捧げるくらいゲームが大好きでなければネトゲ廃人ニートになんかな
「プログラミング初心者」にもなれない人の特徴を考えてみた - タオルケット体操
photo by CollegeDegrees360 曰く、プログラミングという技能は素質に大きく左右されるもので、出来る人間と出来ない人間の間には大きな溝があるという。 これは僕の（大して長くない）経験からしても納得出来る話で、また下記のエントリーなどを参考するに世間のプログラマーたちにしても同様のようだ。 参照: カレーなる辛口Javaな転職日記: プログラマの適性検査 （他にもJoel on Softwareという書籍では「Javaスクールの危険」というタイトルでプログラマーの適正と、そのふるい分けの問題について扱っている。） 教養としてのプログラミング講座 (中公新書ラクレ) 作者: 清水亮出版社/メーカー: 中央公論新社発売日: 2014/03/07メディア: 新書この商品を含むブログ (25件) を見る この話題は有史以来定期的に繰り返されているわけだが、上に挙げた書籍（教養と
エンジニアに「この会社はないわ」と思わせる面接のパターン - タオルケット体操
photo by DonkeyHotey 就職市場は売り手市場になりつつあるだとか、IT業界は人手不足だなどという話を最近はよく聞きます。 が、そういうわりにはマイナビだとかの斡旋サービスが出す雇う側視点の面接ガイドみたいなものが幅を利かせていて、雇われる側が面接の時にどういう基準で会社を選別しているのかみたいなおはなしは見かけない気がします。当たり前ですが、雇われる側にとっても面接とは擬似的にその会社の人間を体験する場（インターンほどではないですが……）なので、実際にやりとりをしてみたところで魅力に欠けるような会社であれば、志望を取り消します。逆お祈りメールです。 そんなわけで、プログラマーが面接を受けて「この会社こわ、入るのやめよ」っておもうような基準についてのお話ってみかけない気がしたので、エンジニア仲間と駄弁ってて出てきた話題だとか独断と偏見から出てきた考えだとかを書きなぐろうと思
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
