これまでいろんな人のコードを見てきて、そのたび不愉快になることがあるので、ここで提案したい。 「check」っていう単語の利用、コーディング規約で禁止にしない？ 「check」って、実に使いやすい単語なんだよ。「ナントカをチェックする」というと、大抵の検証処理の名前としてOKな気がする。なぜなら抽象度が高すぎるから。言い方を変えると、大雑把すぎるから。大雑把だから、大抵のものに当てはまってしまう。また、「チェックする」という表現が半ば日本語になっていることも使いやすくしている要因だ。だからみんなcheckXXXという名前を使いたがる。 しかし、大雑把ということは、第三者から見て大雑把なことしかわからないってことだ。変数名やメソッド名を見ても大雑把すぎて何をやっているのかよくわからず、結局コードを読まなきゃいけなくなる。 かつて、nullCheckという名前のメソッドをしつこくdisったこと

技術書典5にて販売した "pospomeのサーバサイドアーキテクチャ" をBOOTHから購入できるようにしました。 以下から購入できます。 価格は技術書典と同じ1000円です。 booth.pm 技術書典に来てくださった方への特典として価格を少し上げたり、 内容を落としたりしようと思いました。 しかし、遠方のため行けない人がいたり、 予定があって行けない人がいたり、 行きたくても行けない場合もあるので、 特典というのも少し違うかなと思い、価格は据え置き、内容も同じという形で販売しました。 次の技術書典では当日来てくださった方向けの特典でも用意しようかなと思っています。 ちゃんとしたイラストを表紙にした物理本をプレゼントしたり、 一部の内容を落としたりしようかと。 落とす内容は独立して切り離せる内容にしないといけないので、次回はそれも考えて書く必要がありますね。

技術書典5にサークルとして参加することになったので、 書籍の詳細についてまとめました。 techbookfest.org [追記] BOOTHから購入できるようにしました。 pospome.hatenablog.com 書籍のざっくり情報は以下です。 書籍の目次はこちら サーバサイドのアプリケーションアーキテクチャに関する書籍 ページ数は155ページ PDF版のみ 価格は1冊1000円 購入していただけるとその場でQRコードが印刷されている紙を渡すので、そこからPDFをDLしてください。 サンプルコードはGo言語ですが、サーバサイドのアプリケーションアーキテクチャがメインなのでサーバサイドのアプリケーションエンジニアであればGo言語に関わらず役に立つはず かんたん後払いには対応していません 当日まで可能な限り内容を精査するので、内容が一部変更されるかもしれません。 当日は見本誌を用意するの

昨日開催された技術書典5にて、新刊「実践ARKit」と既刊「Metal入門」という2冊の技術書を販売してきました。これまで商業出版も含め何度か技術書を書いてきて、「技術書に儲けを期待してはいけない」1と思い込んできましたが、昨日一日の売り上げは約46万円（詳細は後述）。もしかしたら技術書を書くこと自体でそれなりに稼げる時代が来つつあるのかもしれない・・・と考えを改めました。 （技術書典5。自分のブースからの光景） 自分の書籍の中身やイベントがめちゃくちゃ楽しかったという話は本記事ではいったん置いておいて、そんな「お金」の面について具体的な数字、気付きなどを書いておきたいと思います。 1日の売り上げ詳細 実践ARKitとMetal入門、どちらも製本版＋電子版のセットで2000円で販売しました。どっちが何冊売れたかはちゃんと数えてないのですが、だいたい3:1ぐらいでARKitのほうが多かった感

緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた

anond:20181007134350 嘘か、糞の役にも立たないゴミ情報が多すぎる。 おかげで何かを調べたい時には英語で検索して、日本語の検索結果を排除する設定にせざるを得なくなってる。 日本人のITエンジニアの90％は人に何かを教えられるレベルには達してない [追記] QAサイトが英語圏もゴミなのは同意です。 でもね、日本語圏にはアカデミック界隈の情報がすくないんですよ。何かのアルゴリズム、何かの数値処理など、理論的な背景から実装までを知りたいと思った時に、全く役に立たないんですね。そりゃね、Windowsでアプリケーションを作りたくて、UIコントロールの機能や使い方を知りたい程度なら、日本語情報も役に立ちますよ。欲しい情報が専門化するほど、日本語情報はないか、あってもゴミなんです。

概要 以前はGraceful shutdownをするために以下のようなライブラリを使用していました。 github.com しかしながらGo 1.8 からGraceful Shutdown機能が標準で提供されるようになりました。 今回はその導入方法を紹介します。 環境 golang 1.10.3 これまでの問題 例えば以下のような重い処理がHandlerにあるとします。 簡単のためsleepで実装しています。 func hello(w http.ResponseWriter, r *http.Request) { log.Println("heavy process starts") time.Sleep(5 * time.Second) log.Println("done") w.Header().Set("Content-Type", "text/plain") w.Write([]b

概要 ECS Fargateがリリースされてから検証・導入を進めています。 インスタンスの管理をする必要がなくなり非常にメリットを感じている一方、本番環境で使う上で注意すべき点もあるのでそこをまとめます。 環境 Fargateプラットフォーム 1.2.0 問題点 dev, stg環境で検証してみて、現状感じている問題点を挙げていきます。 同一タスク内のコンテナの起動順序を制御できない 通常のECSではTask Definitionにあるlinks機能によって起動順序をある程度制御できます。 例えば コンテナA links コンテナB だとすると、コンテナBの方を先に起動してくれます。 しかしFargateではlinks機能がそもそもないので、こういった起動順序を制御することができません。 例えばConsul agentを先に起動してアプリケーションサーバはそのConsulから別のマイクロサ