どうしてスタートアップのソフトウェア設計はいつもいつもブッ壊れてるんですかぁ？ - タオルケット体操
そんな皆さまの疑問にお答えします。 スタートアップのアーキテクチャがブッ壊れてるのってなんでェ？ 先にざっくりまとめましょう。 巷でよく言及されるのはカネ、つまりは雇用するエンジニアの能力問題を元凶とする方が多いようです。 スタートアップの内情を知っていれば金と雇用の問題がどれだけ切実であるかについて異論を唱える人はいないとおもいます。しかし僕の考えによればこれはスタートアップのソフトウェア開発が抱える問題のうちのひとつ側面にすぎません。 つまりどんなに優秀な人間をかき集めようがスタートアップのソフトウェア設計は近い将来壊れる宿命にあるということです。 スタートアップの存在意義は未来の不確実性そのもの 普通のやつらの上を行け、ではありませんが。 スタートアップ企業はうまくいくかわからない事業をやることそのものに価値があります。 「誰からみてもうまくいくに決まってる」事業で金も人材も潤沢にあ
実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
共通化という考え方はアンチパターンを生み出すだけ説 - タオルケット体操
共通化を指針にするのはおすすめできない 「共通化」というワードはプログラマーであれば誰しもが一度は聞いたことがあるだろう。そしてもうひとつ、それと対称であるかのように語られるのが「コピペは悪」だ。 ここで僕が異議を唱えたいのは共通化を善とする教義についてだ。世間的に共通化を良いものだとする風潮があるようなので石を投げるために書き殴ろうとおもう。 さて、ぶっちゃけた話、共通化なんてものを念頭にしてコードを書いてはいけない。そんなことをしたら見通しの悪いクソの山が世の中に一つ増えるだけである。 じゃあコピペしろというのかというとそういう話をしているわけではない。僕が言いたいのはコードを設計*1する際に、共通化なんていうゴミみたいな方針を用いるのはやめろということだ。 ならどうすればいいのかというのを頑張って言語化してみると、「抽象化」するというのが僕の語彙の中では正しい。 なぜ共通化するのか
「Reactの難しさ」を分解しよう - タオルケット体操
他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 「テンプレートエンジン」として捉えて、シンタックスを攻撃するのをやめよう ライブラリとしてのReactはとても簡単 Reactの思想を理解するのはチョットムズカシイ 環境構築が難しい JavaScriptそのものが難しい GUIが難しい jQuery時代からのパラダイムシフト フレームワーク関係者の情報量が多い SPAはとりわけ難しい まとめ ずっと感じてたもやもやを書き連ねたら長くなってしまったが、ぼんやりとReactとかなんか難しそうだしめんどくさいから新規案件だけどjQueryでやろっかなどうしよっかなーと迷っている人の指針になってくれればうれしい。 他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 出た時から延々と言われ続けているものの、やっぱり今でもjQueryとRe
覚えるだけでPythonのコードが少し綺麗になる頻出イディオム - タオルケット体操
まえがき 今年の春から今まで、2年ぶりにPythonを沢山書いているわけなんですが、JavaScriptのクソに頭をやられて久しぶり書くだけあって基本的なところから色々と頭から抜け落ちていたわけです。 そんで何か思い出すたびに会社のwikiを使ってメモっていたのですが、せっかくなので少々訂正をしてブログにも書きます。 また、弊社はPython2を使っているので、2が前提の記述になっているところがいくつかあります。なるべくフォローしていますが、参考にする場合は自分が使っているバージョンを確認することをおすすめします。 また、今から新しくPythonでプロジェクトを始めようと思っている人は3系を使いましょう。 知ってる人は当然知ってる、でも結構長いことPythonを書いてても知らなかったりするような小技を載っけました。 なお、メタプログラミングとかの黒魔術っぽい記事のまとめはこちら: hach
英語できないエンジニアだけど外資系に転職してしばらく経ちました - タオルケット体操
僕の英語力について こういう記事って、「英語できない」を過少申告してること多いですよね。「TOEIC820点しかとれてなくて全然ダメなんです>_<」みたいな。アレはなんなんですかね？ ちなみに僕はそもそもTOEICを受けたことがないです。 そんな僕のスペックをまとめると 学生時代に特に苦手意識を持ったことはない（苦手意識を持つほど勉強しなかったとも言える） TOEICを受けたことがない StackOverflowを読むくらいならなんとか 英語で会話したことは（ほぼ）ない 去年初めてヨーロッパに行った際、「tea or coffee?」にcoffeeと答えたらteaが出てきた DMM英会話の無料体験をしてみたら死んだ つまり公式には学校教育でしか英語を学んでいないということになりますね。平均的な日本人って感じだと思います。そして学校の英語教育は役立たずで有名（実際に役立たずっぷりを実感）なん
流行りにのってErgoDox EZを買ってしまった - タオルケット体操
理由 流行り（一部）に乗ってErgoDox EZを買いました。 何故か？ それは私が漢だから。そして超オスの存在…憧れ… つまり、あまりに肩こりがひどすぎるのでいい加減HHKを脱却しようとおもいたったというワケ。 というわけで開封。 くっさい。めっちゃシンナーくさい*1。しかしツヤ消しのブラックといい、見た目はなかなか綺麗です。角度をかえられるチルトもしっかりしていてグッド！ どこをみても作りはしっかりしてます。これから買う方はチルトとアームレストつきをおすすめします。 理由 世間で流行っている様子 感想 デフォルトのキーバインドがイケてねぇ ErgoDoxのキーコンフィグの書き換え方 Vimとの相性が不安 プログラマー以外にはおすすめできない 使いやすさは最高 まとめ 軸ですが、僕はよくわかんないので赤軸を選びました。HHKの静電式と較べてはいけないんですが、まぁそれほど悪くないです。音
言われた仕事を粛々とこなすか、頼まれてもいないことをやらかすか - タオルケット体操
まえがき 多分に考えを整理するためのWIP的な性格を持った文章になります。そして長いです。 「1をきいて10をこなす」的な優秀さか、「1をきいて3くらいをこなしながらabcをやらかす」的なはっちゃけか、どっちで生きるべきかみたいなはなしです。 いくつかのチームを抱えているような会社って、横断的なコミュニケーションや情報共有はどうなっているもんなんでしょうか。ウチは皆無です。正確には、同期でたまたま仲がいいだとか、そういった理由での個人的な繋がりはあるのかもしれないんですけど、組織的な風土や取り組みとしては実質的にほぼ皆無だと言って良いとおもいます。 社内の情報共有がない。でもそれで何か問題があるの？ コミュニケーション皆無だろうが、みんなが暗黙知を抱え込んで仕事をしていようが、それでみんなが（本音: 主に僕が）幸せに働けておカネもがっぽがっぽなら言うことないとおもいます。 が、どうにもうま
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
エンジニアに「この会社はないわ」と思わせる面接のパターン - タオルケット体操
photo by DonkeyHotey 就職市場は売り手市場になりつつあるだとか、IT業界は人手不足だなどという話を最近はよく聞きます。 が、そういうわりにはマイナビだとかの斡旋サービスが出す雇う側視点の面接ガイドみたいなものが幅を利かせていて、雇われる側が面接の時にどういう基準で会社を選別しているのかみたいなおはなしは見かけない気がします。当たり前ですが、雇われる側にとっても面接とは擬似的にその会社の人間を体験する場（インターンほどではないですが……）なので、実際にやりとりをしてみたところで魅力に欠けるような会社であれば、志望を取り消します。逆お祈りメールです。 そんなわけで、プログラマーが面接を受けて「この会社こわ、入るのやめよ」っておもうような基準についてのお話ってみかけない気がしたので、エンジニア仲間と駄弁ってて出てきた話題だとか独断と偏見から出てきた考えだとかを書きなぐろうと思
Pythonのラムダ辛い問題を解決する暗黙のプレースホルダ - タオルケット体操
＊ ネタ元 Rubyのブロックつらい問題を解決する暗黙のブロックパラメータ - Qiita RubyPythonのブロックラムダつらい問題 Pythonでショートコードをしようとおもうと、時々こういうことが起きます。 map(lambda it: it.upper(), ['foo', 'bar', 'baz']) それぞれの要素に対してupcaseを適用する、ただそれだけのためにitを2回も記述しなければなりません。っていうかそもそもlambda:って読みにくいです。 Pythonはラムダをあまり使わない言語なのでこの様なコードを書く機会は少ないですが、それでもちょくちょく出番があり、やがてあなたは辟易するはずです。 <中略> 参考になる例として、ClojureやScalaでは暗黙のパラメータ（プレースホルダ）を導入することでこの問題を上手く解決しています。 <例は省略> やりましょう
GHOST脆弱性の問題を緩和する要素について（ GHOST脆弱性勧告書の一部を翻訳） - タオルケット体操
つい数時間前に存在を知りました。 某ニュースサイトとかで「マジやべえ今すぐ対処しないと死ぬぞ」みたいなことを書かれていたので超焦っていたのですが、かくかくしかじかの理由で独自パッチの作成を検討するために https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt の報告書を読んでいたところ、そこまで超ヤバい急ぎの要件でもなくね？ みたいな感じになったので共有します。 なお、私の英語力がヤムチャレベルであること、ネットワークやLinuxシステムに関わる知識がチャオズレベルであること、急ぎの翻訳なので他の節はほとんど読めていないこと、あくまで2014年1月28日時点での情報であること、などの理由から誤解、誤訳が含まれている可能性があります。 参照するのはあくまで元の報告書をベースにして、あとは自己責任で
Pythonの開発をしている人でPython製の便利スクリプトを導入するならpipsiが便利っぽい - タオルケット体操
pipsiとはpipsi = pip script installer Flaskの人が作ったっぽいスクリプトです。 mitsuhiko/pipsi · GitHub pipsiが流行る気配が微塵もないので書きました。たぶんクッソ地味なのでわざわざ話題にしないんだとおもいますが、個人的には重宝してます。 はじめに このエントリの対象者はPythonでなんかを作ってる人です。つまり、virtualenvを使って仮想環境を切り替えまくってる系の人です。 普段Pythonでがっつり開発しない人はもう、面倒なので普通にグローバル環境にpip installしてパスを通せばいいとおもいます。 pipsiイズ何 さて、virtualenvを使って開発をしていると時々困ることがあります。それはPython製の便利ツール（pipで配信されている）をどう管理するかという問題です。 fabric, ansib
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
