はてなブックマーク

みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは？ おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや

就職して今日からソフトウェア開発者になった人向け。 本気！ どれくらい本気かって言うと会社の新人に強制的に読ませてるくらい本気*1。読破したら偉いとか、興味をもってくれたらうれしいとかじゃない。絶対読め。そして絶対読める。 誰に？ 対象とする人 SIerでWebアプリを作る 研究の道具としてプログラミングをしたことはあるがプロダクトを作ったことがない 今まで書いたプログラミングのコード量が3000行以下 文系出身でプログラミングとか知らない、今日からソフトウェア開発者を目指す 対象としない人 新しいことを知るのが好きで、難しい本ほど興奮する 既にプログラミング経験していて、プログラミングをの腕を上げる具体的な方法を知りたい ソフトウェア開発に興味がない 組み込み系とかソーシャル系とか自社サービスな人は、ネットワークとWebアプリは他の本に変えた方がいいかも 5冊の本 読む本は以下の五冊。そ

十行程度のプログラムが読めること プログラミング言語の文法を知っている 分岐とループを追いかけることができる 変数の状態変化を追いかけることができる 関数呼び出しを追いかけることができる 十行程度のプログラムを複数回書いたことがある プログラムを読んでプログラムの動的な振る舞いを想像できる プログラムの主な処理の結果を想像できる 主な処理の終了条件がわかる プログラムから主な処理を読み取れる 似たようなプログラムを書いて、動かしたことがある 既知のプログラムと読んでいるプログラムの違いがわかる イディオムを知っている イディオムを書いたことがある プログラムがどう動くか知っている 重複したソースコードを関数に抽出できる 重複したソースコードがわかる 同じ入力と出力をもつコードブロックがわかる コードブロック単位で入出力を比較できる プログラムのある機能がソースコードのどの部分に依存している

はじめに 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 | つい全力ツッコミしてしまうエンジニアCEOのブログ | sumyappを読みました。最初ツッコミどころが凄い*1なと思ったんですが、二回読んでちょっと思い当たる節があるなと思ったので書きます。 Rails を勉強しない方が良い理由 Railsにはscaffoldがあるので間口がすごく広いです。実際それを紹介した 15m intro video*2 が理由で人気を博しました。が、奥行きが深い。どこまで学べば「Railsを使いこなせます」って言えるのかまるでわかりません。 鉄板作法が共有されていない 2005年に出てきた割に意外に鉄板作法が共有されていません。 たとえばビジネスロジックをどこに置くのかについては以下のような議論があります やはりお前らのMVCは間違っている Rails の

paiza.hatenablog.com に、面接で落とした理由があります。 最近は技術者が面接をすることが多いです。 技術者は採用面接に不慣れなことが多く、質問が下手くそです。 面接官側の不手際で、コミュニケーションに齟齬があって落ちていることもあると思います。 自分の採用面接経験での「こういうことが聞きたかったんだよ」という辺りを書きます。 実践すれば面接に受かることを保証するものではありません。 1位：自己表現(プレゼンテーション)力 職務経歴を聞かれて、一から十まで細かく説明しようとする人 面接の最初にお互いの緊張をほぐすために、自己紹介をしてほしくて使います。 面接官がどっから本題に入っていいのかわからないので、とりあえず聞いてみます。 30秒〜1分くらいで、簡単に説明してもらえれば良いです。 内容よりは、喋り方を見ています。 評価をするためよりは、これから会話をして行くときに「

僕がNode.jsを熱心に勉強していた頃に、スーパープログラマとして憧れていた人たちが、今何をやっているのか調べてみました。 github.com Express.jsなんかを作っていたtjは、Go言語がメインに書いているようです。 OSS活動自体あまりやっていなさそうです。 github.com Browserifyをつくっていたsubstackは、主にrustを書いているようです。 サーバーを書いていた人はGo言語に、CLIを書いていた人がrustに行くのかもしれません。 github.com Babelを書いていたsebmckもrustです。 github.com Rad VaggはGo言語とPythonのようです。 github.com tjfontaineはOSS活動がほとんど無くなっています。 ここからはNode.jsを去っていない人たちです。 github.com Guill

社内勉強会について僕にも思うところがある*1。 社内勉強会をやらない理由 - 勘と経験と読経 社内内弁慶を社外勉強会に参加させる方法: ソフトウェアさかば 最初に言っておくと弊社は20人くらいしか居ないし、受託開発と派遣が半々くらいのSIerだ。 id:kent4989 の会社とはだいぶ状況が違う。 社内勉強会はやらない 結論から言うと社内勉強会はやっていない。やらない理由は発表者のコストが高くてメリットが少ない。 勉強会のつらさ IT系の勉強会のノリだと テーマに対して興味のある人が少なく参加者が少ない 最新ネタは業務と離れすぎていて、継続する努力がハイコスト過ぎる 研修のつらさ 教育を重視して基礎的な内容をやると 基礎的な内容だと教える側が刺激が足りなくて飽きる 教える側が教えるほどは理解していないので、事前準備がハイコスト過ぎる そんなわけで社内勉強会をやるのはやめました*2。 技術

オブジェクト指向という言葉には オブジェクト指向分析(OOA) オブジェクト指向設計(OOD) オブジェクト指向プログラミング(OOP) の三つの意味があります。 オブジェクト指向初心者泣かせです。 ここではオブジェクト指向設計を説明します。 ソフトウェアの設計 ソフトウェアの設計には二つの側面があります。 作成するソフトウェアの共通部分を探し出しモジュール化する 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする 一つ目のモジュール化は構造化設計からある手法です。 オブジェクト指向設計で特に取り上げる点はありません。 ここでは二つ目の将来の変更のために抽象化することに重点を当てます。 オブジェクト指向設計 オブジェクト指向設計とは多態を実装する部分を決めることです。 多態とはオブジェクト指向言語を活用した次のものです。 変更可能な点に抽象クラス*1 （オブジェクト指向言語

MEANとは MongoDB + Express.js + Angular.js + Node.js を組み合わせてWebアプリケーションを作成することです。 手順 Windows上で簡単なユーザ登録アプリケーションを作ってみましょう。 次の手順で進めていきます。 アプリケーションの雛形を作成 ユーザページを追加 htmlを修正してユーザ一覧を追加 クライアントのJavaScript（Angular.js）を修正 サーバのJavaScript（Express.js）を修正 MongoDBを参照 ユーザの登録機能を追加 完成したものはGitHubにおいてあります。 Chocolatey本体のインストール以外はMinGW Bash*1で実行可能です。 事前準備 ChocolateyでMongoDBとNode.jsをインストールします。Chocolateyをインストールしていなかったら次のコマン

この文章は祈りです。 主にRuby on Railsアプリケーションを想定した話です。 Ruby on Railsアプリケーションでは、Fat Model問題という問題が起きることがあります。 ドメインオブジェクトが肥大化しメンテナンスしにくくなる問題です。 Fat Model問題に対応するためにサービスレイヤーを導入することがあります。 「ドメインモデル貧血症」と呼ばれているアンチパターンです。 ドメインモデル貧血症 ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。 Fat Modelを恐れよ Fat Modelは「単一責任原則」を満たしていないモデルです。 単一責任原則 | プログラマが知るべき97のこと 1つのサブシステムやモジュール、クラス、関数などに

素晴らしいエントリが立て続けに出ているので便乗します。 id:arclampさんのアジャイルがダメだと思う7つの理由 id:haradakiroさんのアジャイルがそんなにダメだと思わない7つの理由 1.全体スケジュールにコミットできない 主語を間違えやすいけど 経営者は顧客やVCと全体の計画にコミットしなきゃいけない の通りで全体スケジュールにコミットできるのはスポンサーだけなんです。開発者は「努力すること」しかコミットできません*1。 現実問題として、プロジェクトを上手くスタートするにはゴールをいつまでに何かって決める必要があります。アジャイル開発でも重視している。アジャイルサムライはインセプションデッキにかなりのページ数を割いています。 2. アーキテクチャ上の無駄が生じる アーキテクチャ設計を慎重に考えても元のビジネスモデルがウンコだったら役に立ちません。困ったことにビジネスモデルは

MQTTってなに？ PUB/SUBプロトコルです。 HTTPと同じレイヤーです、主にTCP上で動きます。 WebSocket上でも使えます。 温度計などのセンサーの計測値を集めるM2MプロトコルとしてIBMに開発されました。 なぜMQTTなの？ 公式には 小さいコンピューター（Rasberry PiやArduinoなど）が安価に開発できる （将来）センサーを載せた小さいコンピューターがIPネットワーク上に乗る データ収集サーバーとTCP/IPで直接やりとりしたい 電力が小さく低スペックなマシンで、扱いやすいプロトコルが必要 個人的には 仕様が短い 公式の日本語仕様がある 動きを確かめられる実装が既にある の点に魅力を感じています。 MQ Telemetry Transport (MQTT) V3.1 プロトコル仕様 PUB/SUBについての簡素な説明 PUB/SUBとは、Publisher

RomeプロジェクトのJavaScriptフォーマッターがリリースされました。 rome.tools ちょうどPrettier を使っているプロジェクトがあったので比較してみました。 本当にめちゃくちゃ速い。 prettierで8秒掛かるのが0.5秒とかで終わる。— ぎゃばん@手洗い (@ledsun) April 6, 2022 prettierを速く動かしたくてparallel-prettierに.prettierignoreを読む修正を加えて動かして速くなったか - Qiita でNode.jsのまま並列化したparallel-prettierを試したときは やったね1.25倍速くなりました！ でした。 それと比べてるとRomeは10倍以上速くなっています。 驚異的です。 JavaScriptパーサーやASTを扱うライブラリーなどの資産がないrustで書き直すのは、大変な労力に思えま

RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ

Node.jsとブラウザどちらでも動くように作ってあります。 作った理由 Google Chrome拡張で使いたかった。探してもURLだけを作ってくれるライブラリがありませんでした。 URLは作ってくれるだけど、ボタンを作る機能は不要でした。 仕様メモ 作るにあたって公式仕様を調べたのですが、見つけられませんでした。 ぐぐって分かった情報を残しておきます。 終日予定(allday event)を作る方法を調べるのに苦労しました。 action（必須） 例 action=TEMPLATE TEMPLATE固定です。 text 例 text=Garden%20Waste%20Collection 予定のタイトルです。 URLエンコードします。 空文字を指定すると（日本語の場合）無題の予定になります。 dates 例 dates=20090621T063000Z/20090621T080000Z

プログラマは勉強し続ける職業です。本を読みましょう。 誰に？ 対象とする人 仕事でWebアプリケーションの一部を作ったことがある 仕事でSQLを書いたことがある 対象としない人 一人でWebアプリケーションを作れる DBの論理設計ができる 5冊の本 デバッグルール 楽々ERDレッスン ノンデザイナーズ・デザインブック プログラムはなぜ動くのか 体系的に学ぶ 安全なWebアプリケーションの作り方 デバッグルール プログラム自体は書けるのに依頼された仕事をこなすのに諸先輩に比べると時間が掛かることがあると思います。掛かっている時間の内訳をみると、プログラムを書くことより書いたプログラムが動かなかった時の原因調査に時間が掛かっていることが多いです。何故時間がかかるのでしょうか？エラーメッセージでググって上手い事解法を引き当てるか、コードを適当に変更して正しく動くことを祈るぐらいしかできないからで

参加した時のメモです。 t-wadaさん Testing Framwork Meeting テスティングフレームワークの歴史 http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。 有史以前 make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。 JUnit Kent BeckがJUnitを書いた。 1994 SUnit 1997 JUnit プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。 テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。 自動テス

技術者が1~3年目で成長するかは自習するかに依存してる。業務とは別に勉強する方法を叩き込めば誰でもそれなりに出来るようになる。 そんなわけで僕の所属している会社では年に5冊指定した本を読ませてレポートを書かせている*1。 なぜレポートを書かせるか 僕の所属している会社が採るような大学生は自習しない。分からないことや知りたいことがあっても本を買わない。業務をやるうちに実地で学べることはあるのだけど、実際に自分がやっていることが世間でどれくらいの位置づけなのか知っておくとなお良い。理想的な手法が使えているのか、それとも現場に合わせて翻訳して使っているのか。本に書いてあることと一致していれば普遍的なことなので覚えておけばいいし、書いていないことをやっているなら、下手をうっているか、現場に合わせた調整をしたかどっちか。そういうことを知っておくと違うプロジェクトに移ったときに同じ名前でちょっと違うこ

我が輩のTDD体験を語る 背景 ここ最近のTDDに関する話の噛み合なさっぷりよ・・・ TDDは死んだ。テスティングよ栄えよ。 by DHH 【翻訳】TDD is Fun 【TDDを再定義したほうがいいって話だったのさ】UncleBob, Martinfowler, DHHのツイートまとめ TDDという名の幻想... 大きな疑問 業務でxUnit使ったテストファーストやってる人はいるの？ TDDは死んでないと言うても、業務でxUnit使ったテストファーストやってる人はいるの？ じゃあ、自分はどうなのか？自分語りをする。 前提 ここで話すTDD xUnitを使ったテストファースト 今回はそれ以外を話さない XPの第一版にはそれ以外の要素は書いてなかった。 俺はそう刷り込まれた。 一番大事だと思う要素から話す。 「これからインスピレーションを得たもっといい方法があるよ」って話は喜んで聞きます。

JavaScriptを書いていてぶち殺したくなった時によく使うリファクタリングです。 1.定義順を整理 JavaScriptパターンの5.4.1 モジュールパターンの開示を参考に、var、処理、API公開の順に並べなおす。 function () { //宣言 var hoge = 'hoge', fuga = ''; //処理 fuga = foge; //APIの公開 return { hoge: hoge, fuga: fuga }; } 2.戻り値をオブジェクトにする 戻り値を増やしたいときにまずオブジェクトに変えてから、値を増やす。 型付けが弱い言語は二つ以上の値を返すのが当たり前なのが凄い。 function () { return { hoge: hoge, fuga: fuga }; } 3.戻り値をオブジェクトでなくす 「戻り値をオブジェクトにする」の逆。 戻り値を一つし

Webアプリケーションのテストに使う端末を決定するために、最初はruby -e 'p %w(iPad Firefox Android).sample'とランダムで値を返していました。 使っていると、ランダムよりは順番がよいと感じました。 また、順番も前回使った端末を覚えていて、その次から実行できると嬉しいです。 そして作ったのが、このスクリプトです。 script = File.read(__FILE__).split("__END__\n").first value = DATA.gets puts value File.open(__FILE__, 'w') do _1.write script _1.write "__END__\n" _1.write DATA.read _1.write value end __END__ iPad Firefox Android 実行すると次のよ

残業の話題がとっても盛り上がっているので参戦。 残業を悪とするチームを作るだけでは全く足りない - Change The Worlds 残業をしない会社を作るために - GoTheDistance 残業を悪とするチームを作ろう - ひがやすを blog 長時間労働・サービス残業は自分の価値を下げ企業存続を危うくする | Act as Professional - hiroki.jp by HIROCASTER ここで考えるのはSIerにてエンジニアの残業を無くす方法です。残業を無くすには労働生産性を上げればよい。労働時間が月184時間以内で売上が今と変わらなければ、給料を上げない限り残業は無くなる。さてSIerにて労働生産性を上げるには？ サービス業としてのSIerの場合 二次請け以下の受託開発と人材派遣型のSIerはサービス業です。売上は労働時間単価の積み上げ、実にシンプルです。 売上

結論 事例：クラウドワークス クラウドワークスは発注者のためのサイト 中間業者中抜きへの期待 先人の失敗 絵や音楽 伝統工芸 価格維持力が失われる 中間業者が必要な構造 クラウドワークスの価格低下構造 受注者は増える 価格下げ圧が強すぎると市場は縮小 中間業者の機能1 参入障壁（受注者のフィルタリング） 中間業者の機能2 案件のバッファリング クラウドワークスさまへのご提案 参考リンク 結論 中間業者を中抜きは不可能。よりよい中間業者による代替えを目指そう 事例：クラウドワークス crapp.hatenablog.com にて、受注者側から見たクラウドワークスの問題点が挙げられています。 クラウドワークスは発注者のためのサイト クラウドワークスとは、そもそもエンジニアの為に作られたサイトじゃなく、むしろクライアント(発注者)がエンジニアを安く買い叩くためのサービスに過ぎなかった また 発注

Mac OS X で Mac に刺したSDカードにddコマンドを使ってOSイメージを焼く方法です。 OSイメージの入手 Downloads | Raspberry Piから好きなイメージをダウンロードします。 特にこだわりがなければ、サンプルが多いRASPBIANが良いと思います。 Download Zipをすると数時間掛かるので、面倒でもBitTorrentをインストールして、BitTorrent経由でダウンロードするのをオススメします。 SDカードの確認 SDカードのデバイス名を確認します。 SDカードをMacに刺し、ターミナルから次のコマンドを実行します。 diskutil list 次のような結果が表示されます。 /dev/disk0 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *251.0 GB disk0 1: E

刺激を受けました。 個人的な思いを書きます 後出しじゃんけんです。 寝言です。 価値観 「初期費用が無料だから私たちは本気です」という価値観はあまり好きではありません。 「斉藤浩司＠帯をギュっとね」メソッドや「苦しければ報われる欺瞞」に近いものを感じます。 お客にリスクを負ってもらって、それに報いる方がより本気のように感じます。 商売として お金は商売の血液 1000万円の資金を全額、保証金としてロックするのは商売として考えると微妙です。 商売お金をお客様とそのお客様と自分たちと協力会社と・・・の間を血液のように流す活動のことです。 バッファとして30%ほどをプールするのは良いですが、100%プールするのはいけません。 脾臓に血液を貯めても全身に巡らなければ死んでしまいます。 *1 気が長い 2,3年続かないとペイしない契約で、 成り立つのはファンドや保険などの数百〜万契約を束ねられる商売