短期間で新技術を学ぶ技術2. 自己紹介 大仲 能史 a.k.a. @onk 1982年12月18日生 33歳 ドリコム 10年目 (中途入社 2社目) 大学中退 → 派遣 → エージェント経由転職 趣味：問題解決とコードレビュー 肩書：スペシャリスト (アプリケーションエンジニア) フロントエンドからインフラまで
ドキュメントを書く技術 - blog
READMEを始め、ソフトウェアのドキュメント全般を書く技術というものをもっと洗練させていきたい。要件定義書のようなものだけでなく、開発方針や設計方針、API定義などなど。 これらのドキュメントをしっかりと整備するだけで、レビューの質も上がり新しい人が入ったときもスムーズに意識のズレなく開発ができる。はずだが、なかなかドキュメントの上手い書き方や管理の仕方というものは、コーディングのそれとは違い議論が活発ではない。 最近試してみたこと そういったドキュメントの中でも、"開発方針"や"設計思想"をどう残していくかということを考えている。それらを残しておくことで、コーディングのときも立ち戻る場所ができ、大きく道を踏み外さなくなる。 例えば、レイヤードアーキテクチャのようなものの"境界"をドキュメントにしていく。MVCでもクリーンアーキテクチャでも何でも良いけど、それらのアーキテクチャではそれぞ
Goへの誤解について
よくGoで誤解されるポイントについて個人的な見解を書いておきます。 今回の記事はGoアドベントカレンダー2017 その3の20日目の記事です。 使ってないパッケージがコンパイルエラーって面倒じゃね？ さっさとgoimportsかgoreturnsを保存時に自動実行するエディタ環境を使いましょう。 gofmtも一緒に実行されていいことずくめですよ！ インターフェースがnil判定出来ないパターンがあるのダメじゃん？ 最初は私もそう思いました。しかし、typed-nilがnilリテラルと比較できなくなったのは 「nil判定サボったままinterface型に変換した」からでサボらなければ全く問題にならないのです。 map,sliceが不便？ map,sliceはメソッドが一切ありません。 極論をいうとGoのプリミティブ型みたいなものなのです。 ユーザーが欲しいものはmapやsliceを駆使して各自
A Tour of Goを終えたあなたにおすすめのGoを勉強するためのリソース - すずけんメモ
今年も夏のインターンで学生にGoの講義をします。多く寄せられる質問が「A Tour of Goを終えたのですが、その後に何をやるのがおすすめですか？」というものです。学生に限らず、言語を学ぶ方はプログラミングそのものに対する慣れやバックグラウンドも違います。そこでなるべくいろんな方の参考になるように、おすすめな本なりページなり方法なりをまとめてみます。 わりと多くの人におすすめ 「プログラミング言語Go」（Alan A.A. Donovan, Brian W. Kernighan著）です。通称GOPL。 http://www.gopl.io/ 柴田さんによる日本語翻訳もあります。 https://www.amazon.co.jp/dp/4621300253 Go言語のイントロダクションから始まり、型・インタフェース・並列性の説明などが丁寧にかかれています。私がGOPLを良いと思う点は、例示
良いネーミングをするために覚えておきたい英語のルール5つ - プログラマー幸福論
Photo by muraterturk こういった記事って、ネーミング規則や慣習の視点から書かれていることが多いんですけど、この記事では、英文法に視点を置いて、参考になりそうなことをいくつかピックアップしてみたいと思います。 「省略形は使わない」などの規約的なものは、各プロジェクトのルールに従えばいいので、ここでは書きません。あくまで英語という視点から書いているということを、ご理解ください。 Rule 1 : “検索”は名詞 一般的な英語辞書のルールでは「検索」は、動詞ではなく「検索する」が動詞になります。「検索」は、検索することの名称 だと考えられるため、動詞ではなく名詞として扱います。 英語辞書には、日本語の品詞ごとに表記のルールがあります。これが理解できていると、和英辞書などで品詞を意識して検索できるようになります。以下に、一般的な英語辞書の表記ルールをまとめてみました。 ＜各品詞
プログラミングにおける認知バイアス - Frasco
開発者として、私たちは生産性を妨げる様々な問題をよく知っています。しかし、広い視野で物事を見ることに関して見過ごしがちです。 認知バイアスにより、生産性の低下、バグ、フラストレーションを招く可能性があります。これらの影響を最小限に抑えることができれば理想的です。本記事では、プログラミングする際に知っておくべき5つの認知バイアスを示します。 双曲割引（Hyperbolic Discounting） 後の利益よりも直近の利益を優先する あなたはテストを書くのを遅らせたことがありますか？Vim を使う際、矢印キーを使ってカーソルを移動させたことがありますか？おめでとうございます、それが双曲割引です。HJKL による慣れない操作を覚えるよりも、矢印キーを使用するほうが楽でいいでしょう。しかし、一度 HJKL による移動方法を学ぶと、将来の利益は遥かに高くなります。結果として、あなたは多くの時間を節
プログラミングの経験は役に立つ 〜 論理的思考と抽象化思考の応用 | Social Change!
プログラミングには、論理的に考える力と抽象化して本質を捉える力が求められる。これらは、なにもプログラミングに限らず、あらゆる仕事の場面で役に立つ。むしろナレッジワーカーにとっては基礎力といっても良いのではないだろうか。 本記事では、新米のナレッジワーカーが最初に身につけておくと良い論理的思考と抽象化思考について、プログラミングで鍛えられることについて考察した。 ビジネスの共通言語としての論理的思考 仕事をしていても、なんとなく考えたことは自信を持つことができない。だから、なんとなく説明しても伝わらない。そして、なんとなく実行したら、成功しても失敗しても、なんとなくしかわからない。なんとなくでは再現性がない。 論理的に考えるということは、選択肢を考えて、そこから選ぶ理由を考えることだ。そうして考えたことは、説得力がある。世の中には絶対の正解はないから、正しいかどうかは出せないが、少なくとも仮
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
How Does a Database Work?
What format is data saved in? (in memory and on disk) When does it move from memory to disk? Why can there only be one primary key per table? How does rolling back a transaction work? How are indexes formatted? When and how does a full table scan happen? What format is a prepared statement saved in? In short, how does a database work? I’m building a clone of sqlite from scratch in C in order to un
ブラウザ拡張の開発をTypeScriptで爆速で始めるやつ作ったので紹介 - クフでダローバルな日記
先日、動画に突然「熱盛」を表示するとかいうクソChrome拡張を作って公開しました。 動画を再生しているとたまに熱盛と表示されてしまうchrome extension作ったから見てhttps://t.co/KGdPKFvjuP pic.twitter.com/ocyqJWSBBe— まざっち (@mazamachi) 2017年8月29日 めっちゃバズって結構インストールしていただけました。うれしい。 やっぱりこういうのは鮮度が大事で、思いついてから公開までを数日にとどめたいところですね。 とはいえ、Chrome拡張機能をシュッと作るためには Chrome拡張の作法に則った設定ファイルの作成 （manifest.jsonなど） ES6/TypeScript や Less/Scss などのトランスパイル自動化 開発版とリリース版の分離 などなど、設定事項が多くてかなり面倒です。 この記事は、
賢い質問のしかた
翻訳： アラビア語 インドネシア語 ベラルーシ語 ブラジルポルトガル語 中国語 チェコ語 オランダ語 フランス語 グルジア語 ドイツ語 ギリシャ語 ヘブライ語 ポーランド語 ポルトガル語 ルーマニア語 ロシア語 セルビア語 スペイン語 スウェーデン語 タイ語 If you want to copy, mirror, translate, or excerpt this document, please see my copying policy. 多くのプロジェクトのウェブサイトがヘルプの項目からこのドキュメントにリンクを張っている。それは私達の意図した使い方なので構わない ―― しかしあなたがそのようなリンクをプロジェクトのページに追加しようとしているウェブ管理者ならば、リンクの傍らに目立つように、私達があなたのプロジェクトのサポート窓口ではないことを明示してほしい。 その注意書き無くし
技術系メーリングリストで質問するときのパターン・ランゲージ
目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー＆ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま
Go の interface 設計 - Block Rockin’ Codes
history 13/3/31 Tag について追加 intro Go を触ってて interface を用いた設計がまだまだよくわかってなかったので、一旦まとめることにしました。 Go には明示的な継承の機能は無く、 interface も例えば Java のそれとはかなり毛色が違うので、(Class ではなく) Struct の設計に結構癖があると感じます。 Go の interface は言語設計的にもかなり尖っていて、 Go という言語を強く特徴付けていると同時に、 Go 言語自体の開発者たちもこの機能をかなり重要視しています。 例えば、 Go の開発者の一人である Russ Cox 氏によれば Go's interfaces―static, checked at compile time, dynamic when asked for―are, for me, the most
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Hello Worldの後に何を作るか - razokulover publog
新しい技術を学びはじめるとHello Worldのその先で何を作るか詰まってしまうことがよくある。 最初から作りたいものがある人はそれ作ったほうがいいし、実務で導入できたりするなら一番手軽で学びが多いのだが中々そうもいかないのが人生というもの。 そういう人にとってはHello Worldからある程度使えるもしくは本番投入時に選択肢にできるレベルになるための道筋があると便利だなーと思う。 自分はWeb系の人間なのでフロントエンド/サーバーサイド/モバイルアプリという感じでまとめてるが、インフラ屋やハード他デザイン系の技術はまた違うと思われるのでこれはあくまでも自分の場合はということで。 共通 言語機能を一通り試す(A Tour of Goみたいな感じで) 基本的な型/制御構造/IO周り/クラス/文字列操作/正規表現/よく使いそうな標準ライブラリ その言語固有の機能は重点的に(goだったらgo
How Command Line Parameters Are Parsed
2.1 Example 1: Bash Shell If you launch a program using the Bash shell command line, The Bash shell is responsible for turning the string provided by the user into the argv[] argument vector which is then passed to the program. For the Bash shell parameter parsing rules, the following links provide some information: http://www.gnu.org/software/bash/manual/bashref.html#Quoting http://linux.about.c
CHANGELOG の書き方 - 角待ちは対空
VS Code の拡張作っている際に CHANGELOG.md が自動生成され、書き方はKeep a Changelogに従えと書かれていたので紹介する。 ここに書かれていることは絶対ではなくただ提案しているだけである。意見がある人は話し合おうという温度感っぽいので、納得いかない場合は issue 立てると良いと思う。 僕自身はなんでもよくてある程度型が欲しかっただけなのでこれからはこれに従って書いていこうと思う。ただまぁ Semantic Versioning もそうだけどちゃんと従おうとすると以上にだるくなってくるので雰囲気従うくらいだと思う。 CHANGELOG の原則 機械的に生成するのではなく人間の手で書く 各セクションへのリンクが容易にできる 1つのバージョンごとに1つのサブセクションを作る リリースは新しいものが上に来るようにする 日付のフォーマットは YYYY-MM-DD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Oss貢献超入門
GAE/Go コトハジメ
知っているようで知らないWebサーバアーキテクチャ
