2021/01/19 の Forkwell Engineer Career Study の資料です
はじめに よく言われるように、ソースコードというものは書かれることよりも読まれることの方が多く、それゆえ読みやすいコードを書くということが非常に重要です。それはテストコードにおいても同様であり、プロダクトコードと同等に資産として扱う必要があります。 テストコードは具体的な値を用いて記述し、また複数の変数の値の組み合わせでテストケースを起こすため、プロダクトコードと比べて冗長になりがちです。 書籍『リーダブルコード』の14章でもテストコードの読みやすさについて触れられていますが、本稿では読みづらいテストコードをリファクタリングして読みやすくするためのテクニックを紹介したいと思います。 なおサンプルコードはJavaScriptで記述されており、そのテストコードはJest1を用いて書いています。 ソースコードはGitHubにあります。 リファクタリング(その壱) 以下の、決して読みやすいとはいえ
久しぶりに物理本を読んだけど、やっぱ物理はええな・・かさばるとこ以外。 せっかくなので読書感想文と、特に印象に残った部分を、章ごとに書いておく。 第1章: 達人の哲学 この本を読んでいくにあたって、そもそも達人とはなんぞやという話がメイン。 プログラマーというより、いわゆる社会人としてこうあれみたいなテーマで書かれてて、なんかみんな読んだらいいのではと思いました。 物事をうまく進捗させるために、 まず何を言いたくて その結果どうしたいのかまで考えて 相手の状況やタイミングを見計らって コミュニケーションを実行する・されると、あれこれスムーズにいきますよっていう。 このテクは中々に便利で、日常生活でもそれこそ夫婦間とかのコミュニケーションでも使える話かなーと思ってて。 ただ自分の場合はこれをやりすぎて、質問してるはずが誘導尋問みたいになっちゃうときがたまにある・・。 第2章: 達人のアプロー
この文章について これは Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」で基調講演をするにあたって、登壇内容を整理するために書いたものです。登壇内容とは一部に差異があります。 イベント映像 この文章はむちゃくちゃに長いので、登壇映像を見たほうがいいかもしれません。わたしの発表は13:23くらいから30分ちょっとです 登壇資料(内容は同一です) https://speakerdeck.com/ymrl/webenziniatosite-imazhi-tuteokitai-webakusesibiritei https://docs.google.com/presentation/d/1uhCvhh6sZCPUnReSBVDjvGfNAOTKbZ5Sxs8fYMlxMsI/edit?usp=sharing 目的 Web業界で「エンジニア」の肩書で仕事して
この記事は、JavaScript で Flash Player の実現を頑張った(もしくは現在進行系で頑張っている)人たちの集う Flash Advent Calendar 2020 に参加しております。 私は過去に自分が設立した会社で ExGame という HTML5 実装の Flash Player(正確には Flash Runtime Engine)を開発し、その会社ごと DeNA に買収(M&A)されました。あまり出来ない体験であるのは間違いないので、Flash が終了を迎える今、改めて振り返ってみようと思います。 Flash Player の開発 今から 10 年前の 2010 年、ちょうど iPhone が普及し始めてきてガラケーのシェアが 8 割から 6 割くらいに落ちようとしていた時期に、私は Flash Player を JavaScript で実装していました。以前この
電通デジタルは2020年12月18日、「日本における企業のデジタルトランスフォーメーション調査(2020年度)」の結果を発表した。それによると、デジタルトランスフォーメーション(DX)に着手した日本企業の割合は74%で、前年に比べて4ポイント増加した。同社は「新型コロナウイルス感染症(COVID-19)の感染拡大が日本企業のDXを後押ししている」とみている。 DXに取り組んでいる企業の割合は74% DXの取り組み状況について聞いたところ、DXに取り組んでいる企業の割合は74%だった。内訳は「完了済み」が7%、「複数の領域で取り組み中」が33%、「一部の領域で取り組み中」が26%、「計画を策定中」が8%だった。現在取り組みを進めてはいないものの「将来的に着手予定」と回答した割合は13%あり、先の結果と合わせると何らかの形でDXに取り組もうとしている企業は87%に上る。
Merpay Advent Calendar 2020 の16日目は、メルペイ Android チームの yhanadaが担当します。 著者のメルカリ/メルペイでのAndroidエンジニアとしてのキャリアは、12月でちょうど4年になりました。チーム内での役割としては、通常の機能開発以外に、DEX(Developer EXperience)改善というプロジェクトで、リファクタリングを行ったり、ルールを考えたり、不要なものを取り除いたり、などエンジニアの負担を減らす活動を行っています。 つまりDEX改善の対象となるのは、リファクタリングなどのコード改善だけではなく、時に他チームとの交渉や調整など組織的な部分もエンジニアリングの対象に含まれます。 本記事では、このDEX改善活動の紹介を行うとともに、過去のブログ記事「マルチモジュールなプロジェクトにおける画面遷移の実装」での残課題であった、マルチ
これは「フィヨルドブートキャンプ Part 1 Advent Calendar 2020」の13日目の記事です。 フィヨルドブートキャンプ Part 1 Advent Calendar 2020 - Adventar 昨日はmasuyama13さんのプログラミング学習中の人が稼働中のシステムに不具合を発生させた話 - No Solution for Lifeでした。 Part 2もあります。 フィヨルドブートキャンプ Part 2 Advent Calendar 2020 - Adventar 朝は1杯の白湯からスタートしています、にしめです😌 人生初のアドベントカレンダーです😆 中身は至って真面目な記事ですので、最後までお付き合いください。笑 初めに、私は2020年8月から大名エンジニアカレッジとフィヨルドブートキャンプでプログラミングを学んでいます。 今回は私が約4ヶ月間プログラミ
Greenやyentaなどを運営する株式会社アトラエという会社でエンジニアをしているタガミショウゴです。弊社ではほぼ毎月LT大会を開き、事業部内外でエンジニアの情報共有をしています。そのなかで個人的に感じた「LT慣れするためのポイント」みたいなことをまとめます。 是非みなさんのご提案・ご意見もコメントにていただけると嬉しいです! ほとんどのLTは雑談 さて、エンジニアという職業柄、社内外でLTや大きなカンファレンスなどで登壇する機会が多いですよね。世間一般を見渡しても、ここまで"個人として"人前で話す機会が多い職業は珍しいのではないかと思います。 とはいえ、全てのエンジニアがLTが得意なわけではなく、日頃からLTに慣れているのは1,2割くらいなんじゃないかなと感じています。残りの大多数は 人前で話すのが苦手 資料作るのが面倒臭い わざわざ話すようなネタがない アウトプットしてマサカリ投げら
凄惨度:低 またやらかす確率:中 俺TUEEE系エンジニアとは ※ ここの章は独断と偏見がかなり入ってるのでネタとして読んでください 俺TUEEE系エンジニアとは、 「まあどんなセキュリティもオレには全然関係ないけど」(出典:BLOODY MONDAY) ウィザード級ハッカー(出典:ne0;lation) 等に代表されるようなある種の厨二的価値観を捨てきれずに社会人になってしまったエンジニアです。 俺TUEEE系エンジニアは基本的に虚栄心があって傲慢です。だいたい自分の開発環境に酔いしれてます。生産性を高めて、作業のスピードを上げ、他の人に一目置かれることを生きがいとしています。 まあざっくりいうと俺TUEEE系エンジニアとは、なんとなくハッカーを気取りたい、人と同じものを使いたくないエンジニアのことです。 俺TUEEE系エンジニアは、だいたい自分の作業用PC(クライアントPC)を完全にL
[2020.12.8 追記] ブコメでEMが何かわからないと書かれていたので補足。EM = Engineering Managerです。EM菌ではありません!!! [追記ここまで] 今の会社でお世話になったEMの人たちのマネジメントがとてもよかったので育休で全てを忘れる前にメモを残す。EMの話題はよく見かけるけれど、マネジメントされる側の視点で語られることがあまりなかった気がするのでいい記録になるかもしれない。 前提 自分: メンバー(マネジメントされる側)。Androidエンジニア。ある程度放置されても自走できる。 EM: 一人ではなく複数。(歴代という意味。同時に複数人のEMにマネジメントされたという意味ではない。)彼らはみなAndroidエンジニアではないがモバイルもしくはフロントエンドのエンジニア。なので技術の相談はしないが、開発業務そのものについてはとても詳しい。 組織: エンジ
プログラミングPerl〈VOLUME1〉 作者:ウォール,ラリー,オーワント,ジョン,クリスチャンセン,トム発売日: 2002/09/01メディア: 単行本 何度も読み返す技術書の話題で忘れてはいけないのがPerlの作者であるLarry Wallが書いた「Programming Perl」。 この本、Perlというプログラミング言語に関する解説書である共に、定期的にブログなどで話題になる「プログラマの三大美徳(無精、短気、傲慢)」に ついて解説されている原典でもある。 この三大美徳…意外と原典ではストレートには語られていない点も興味深い。三大美徳の中身は散々語られているので、ここでは原典でどのような流れで語られているのか調べた。 Perl自体の人気もだいぶ下がっているし、日本語に訳されているのはPerl 5.6対応(20年前!)の第3版しかなく、2012年に出版された第4版は日本語には翻訳
1985年にAppleを追放されたスティーブ・ジョブズ氏が創業した「NeXT」は教育用・ビジネス用のワークステーションのメーカーで、1996年にAppleに買収され、ジョブズ氏がAppleに返り咲くきっかけとなりました。NeXTが開発したオブジェクト指向型OS「NeXTSTEP」はその後のmacOSやiOSの基盤となっています。さまざまな質問に対して専門家が回答する質疑応答サイト「Quora」に投稿された「NeXTのエンジニアはどんな感じで働いていたのでしょうか?ジョブズ氏は普段から従業員と交流していたのでしょうか?」という質問に対して、当時を知るエンジニアたちが回答しています。 What was it like to be a software engineer at NeXT? Did workers interact with Steve Jobs? - Quora https://
ブログ読者のみなさん、はじめまして。 株式会社セガのベテランプログラマー阿部です。 このエントリーではデバッグ手法のあれこれについての体験談と、デバッグをテーマに一昨年に実施されたプログラマー向け新人研修の概要をお伝えしたいと思います。 EXE ファイルのデバッグ イーサネット絡みのデバッグ 周辺機器絡みのデバッグ デバッグスキルブートキャンプ 黒子に徹する、裏方系エンジニア EXE ファイルのデバッグ 同僚が作った EXE ファイルが手元にあり、あなたはこれを Windows で起動しようとしています。 起動してみたところ何も反応がなく、しかもそれは想定外のことでした。 「何コレ、動かないんだけど」とあなたが同僚に文句を伝えると、同僚はあなたに返します。 「こっちでは動いてるよ」 困りましたね。 あなたの手元には EXE のソースコードも無ければ、Visual Studio もありません
さくらインターネットでフロントエンドエンジニアであるダーシノさんが、見つけたバグをプログラマーに分かるように伝えるための報告書の書き方という記事をアップしている(さくらのナレッジ)。それによれば、バグ報告の基本は「1Issue 1Bug」、「事実のみを伝える」、「バグと要望は分ける」の3つあるのだという。 一つ目の「1Issue 1Bug」では、1つのバグ報告に含めるバグは1つまでというもの。報告に複数のバグが存在してしまうと、最後の1個が直らないという理由で修正の完了報告ができず、永遠にクローズできない場合があるためだという。 2つ目は「事実のみを伝える」こと。動きませんだけではなく、どういう状況で動かないかを的確に伝えること。またバグに対する怒りを報告に入れてきても対応できないので、感情と切り離して事実のみを伝達するようにしてほしいとしている。 3つ目は「バグと要望は分ける」という点。
プログラミング教育が小学校でも始まりましたが、中高生のなりたい職業ランキングでも、「プログラマー」が上位に入っています。それでは、プログラマーとはどんな人たちなのでしょうか? 自身もプログラマーだった角川アスキー総研の遠藤諭氏が、その正体に独自の視点で迫ります。 プログラマーってどんな人たち? どんな人がプログラマーに向くの? プログラムをつくることをプログラミング、そのプログラミングをする人を「プログラマー」と呼ぶのはご存じのとおりです。 ひとくちにプログラマーといっても、「職業がプログラマーです」という人もいれば、中学生で大人なみにプログラミングができる子は「中学生プログラマー」などと呼ばれたりします。日常的にプログラミングをしているような人をプログラマーと呼んでいるのだと思います。 私自身、以前は仕事でプログラミングをするプログラマーという職業をしていました。銀行のオンラインシテスム
拙著『[改訂新版] プログラマのための文字コード技術入門』(技術評論社,2018)についての感想で,初版にAppendixとして入っていたSKKとEmacsによるJIS X 0213対応の話が無くなっていることを惜しんでくれているものがありました。 これは初版執筆時に著者(私だ)がEmacsとSKKを使ってEUC-JIS-2004のプレーンテキストとして原稿を書いていたことを紹介し,当時の一般的な日本語入力環境が抱えていた問題点をこれによって解消できることを説明したものです。 当時の日本語入力環境というのは,おおまかにいえばJIS X 0208の第1・第2水準漢字に制約されており,それ以外の文字は入力できないか,できたとしても単漢字変換や文字パレットのような使いにくい方式によるしかないというものでした。そういう状況を改善し,現代日本で使われている文字は第1・第2水準漢字に限らず,分け隔てな
概要 タイトルの通り、他言語から入門した人が最低限気にするべき、ネーミングルールをまとめました。 対象読者 Goの基本構文を理解している人を対象読者としています。 この記事で説明すること、説明しないこと 説明すること Goのファイル名、変数名などの名前付けに関するルールや慣例などを説明します。 説明しないこと 名前付け以外で気をつけるべきGoの書き方[1] がいくつかあります。 しかし、それらに関してはこの記事では説明しません。 筆者のバックグラウンド プログラマ歴はもうすぐ8年程で、Goの他には以下のような言語の経験があります。 JavaScript TypeScript PHP Ruby Java Scala Goは少し前に書いて、一時期書かない時期が続いていましたが、最近また書いています。 トータルするとGoの経験は1年半程度です。 意識すべき名前付けルール package名 利用し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く