はじめに 都内でひっそり見習いエンジニアをしている@noshishiです。 addしてcommitするプログラムの作成を通じて、Gitを内部から理解しようという記事です。 前書き 昨年末、Gitの記事を書いて、理解できたなら作れるのではと思いったったのがこの記事の出発点です。 これを機に新しいプログラミング言語にも触れてみて、いろいろ学べたらと思いRustで今回挑戦しました。 （この時は、新たなことを同時に取り組み絶望すること知る由もない著者でした。軽い気持ちで手を伸ばした自分をしばきたいです。。。） 実際に作成した（継続開発中ですが）リポジトリは、こちらです。 ※一応ローカルでの一直線の開発はできそうな程度までは作成できました。コードのしょぼさはご容赦ください。 この記事だけでは説明しきれない部分があることをご容赦ください。 もちろん、間違い等あれば、ぜひコメントいただけると幸いです。

はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write

最近社内でビルドの手順がちょいちょいMakefileで書かれているため、意外と知らなそうなmake及びMakefileの基本的な使い方をまとめてみました。 参考図書はこちらです https://www.oreilly.co.jp/books/4873112699/ 。 基本 まずは基本から。makeの本来の用途は、ソースコードのビルド手順を自動化することで、Makefileはその手順を記載したファイルになります。主にC言語をターゲットにしています。 一番基本的な内容はターゲットと依存、そしてビルド手順の3つを記載したルールで構成されています。たとえば、次のように書きます。

まず11位の「クラウドプラクティショナー」ですが、2018年に新設されたAWSのエントリーレベルの認定です。AWSの基本的な概念や、AWSのベーシックなサービスの特長、請求・アカウントマネジメント・料金モデルなどに関する理解が問われます。エンジニアだけでなくマネージャーや営業など様々なポジションを対象とした認定であるため、問われる知識の範囲は意外に広いです。ただ、知っていれば解ける問題が多いため、この順位にしています。 10位の「Alexaスキルビルダー - 専門知識」は、文字通りAlexaのスキル開発に関する知識が問われます。専門知識と銘打たれていますが、内容自体はそこまで難しくなく、Alexaスキル開発に関して知っていれば解ける問題が多かった印象です。これまでにAlexaスキルを開発したことがあり、クラウドプラクティショナーレベル以上のAWS知識があれば、問題なく合格できると思います。

どうも。フロントエンドエンジニアの @Quramy です。 さて、前回、1日10万枚の画像を検証するためにやったことで書いているとおり、reg-suitという画像に特化した回帰テストツールをメンテしています。 画像回帰テストという文脈において、差分の可視化方法はとても重要なファクターです。なぜなら、画像(=スナップショット)に差分が発生したからといって、それすなわち棄却、というわけではなく、その差分の内容を判断して、意図せぬ変更であれば棄却、意図した変更であればexpectedを更新する必要があります。すなわち、ワークフローに目視による差分のレビューが発生するのです。 そこで、少しだけ異なる2枚の画像について差分を効果的に可視化する、というテーマに向き合ってみました。 主にC++とOpenCVでの実装ですが、これらの知識が無くとも読めるよう、コードやAPIへの言及を少なくして、中間画像で説

英語サイトでは、日本語のサイトでは絶対に手に入らないレベルの記事がわんさか読めます。今日はCodeProjectよりシステム構築をする上で知っておくべき深い知識を解説した記事を3行要約と共にご紹介します。 C#と.NETの記事 C#や.NETのかなりディープな記事たちです。日本語ではあまり見かけない深い部分まで知れます。 ■高パフォーマンスなクラスのデザイン方法 Performance Considerations of Class Design and General Coding in .NET - CodeProject ・クラスvs値型のメモリ使用の詳細 ・値型のGetHashCodeとEqualメソッドをオーバーライドする ・シールドクラスによりVirtualメソッドを避ける ・インターフェースのDispatchについて ・ボクシングを避ける ・for vs foreachはfo

一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを

「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected

コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か

ねとけん Advent Calendar 2015 の 24日の記事です．一応ガジェットネタです． 2021/10/02 古い記事ですが見てくれる人がいるようなので少し追記しました． プロローグ(※フィクションです) コンビニ帰り，マンションのエントランスで家の鍵を持っていないことに気付きます．鍵は家の中＝部屋の鍵は開いている，ということなのですが，マンションのエントランスにあるこいつが帰宅を阻みます． こいつです．拡大します． アイ○ンです．色々なところで見かけます． こんなとき，フィクションの世界なら，仲間の凄腕のハッカーが怪しいカードをスリットに挿しこみ，接続された端末に謎の文字列がしばらく流れたあと，めでたくドアが開くのですが，残念ながら都合よくそんなハッカーの連れがいないし，そもそもカードを挿すスリットもありません．また，多くの場合，管理会社や不動産会社が使う番号が設定されていた

この記事では、ドワンゴから今秋リリースされた 「ニコニコ漫画」iOSアプリ の開発での取り組みや内部の設計、ニコニコ漫画アプリのこれからについてご紹介します。あまり変わったことはやっていないとは思いますが、よくあるアプリ開発の一例としてご覧いただければと思います。 なお、一応お約束として書いておくと、この記事は個人の見解であり、所属する組織の公式見解ではありません。 はじめに "ニコニコ漫画"は、縦スクロールでサクサク、マンガを読めるのはもちろんのこと、新感覚のダイナミックな見開きページ表現を楽しめたり1、紙芝居のような形式のマンガが読めたりするなど2、かなりアグレッシブなマンガアプリ3です。 読み手はもちろん、マンガの作り手が作品を公開して嬉しい気持ちになれるサービスになっているかと思います。まだ使ったことがないという方は、この機会にご利用いただければ幸いです（宣伝）。 サービスもアグレ

はじめに Electronいいわー ChromiumとかNode.jsの知見もあるといいらしい *1 でもChromiumとかようわからんぜ この際勉強しちまえばいいじゃん！ 本エントリはElectronを構成する要素の一つ、Chromiumのアーキテクチャについて初心者が入門してみたものです。 Chromiumドキュメントを読む Chromiumの仕組みを優しく解説した本やエントリはざっと探した限りはありません。 そういうのが必要な人がふれる領域の話ではないのでしょう。 必然的に英語で書かれたドキュメントを読むことになります。 Chromiumプロジェクトはリンクの樹海のようになっていて迷いそうです。 Developer向けドキュメントは以下のリンクを辿って行くとみつかります。 For Developers > Design Documents - Engineering design

URLYou can post either your article on Qiita or your blog post. About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)

トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA

POST /post HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar 1行目は request-line で、 method URI HTTP-version の形をしています。URIはホストを含めた絶対URIの場合と、ホストを含めない絶対パスの場合がありますが、絶対パスの方が一般的です。 2行目から空行までが request-header です。各行は field-name: field-value の形をしています。 field-name は大文字小文字を区別しません。 request-line から request-header とそれに続く空行まで、改行は CR LF になってます。Windowsでよく見る改行コードですね。 meth