フィヨルドブートキャンプのコードレビューでよく指摘してるシリーズです。 次のようなパンを焼くRubyプログラムがあります。 このプログラムはどういう工程を経てパンが焼かれるのか、ぱっと把握できますか? def main パンを焼く(粉, 水) end def パンを焼く(粉, 水) 焼く(パンを発酵させる(粉, 水)) end def パンを発酵させる(粉, 水) 発酵させる(パンを整形する(粉, 水)) end def パンを整形する(粉, 水) 整形する(パンをこねる(粉, 水)) end def パンをこねる(粉, 水) こねる(粉, 水) end main 上のプログラムは次のように書いても同じように処理されますが、工程の全体像がつかみやすいのはどちらでしょうか? def main 生地 = パンをこねる(粉, 水) 整形された生地 = パンを整形する(生地) 発酵した生地 = パ
もくもく会で話している中で、「技術書を読んでも頭に入ってこないし、プログラミングスキルが上がらない」という話になり、そのよさげな説明を思いついたので共有します。 具体的な話としては「本を読んでもスキルアップした感じがしない。それで本をよむモチベがわかない。」というものでした。これは僕もとても共感します。バックエンドエンジニアでいくつか有名な本があり(例えばPoEAAやDDD本)、読まないといけないと思い手を出しました。しかし、何を言っているかわからずひたすらに苦痛で、読み切ることができませんでした。結局これらを読み終えることができたのは、業務経験を4年ほど積んだあとでした。 なぜ、本を読んでも苦痛なのか、頭に入ってこないかを、今振り返ってみると、「全体感」と「土地勘」という例えで説明できるのではと思いました。 まず、前提としてあなたが新しい土地に引っ越してきたとします。その地域のことは全然
[速報]「Hey, GitHub! 」、GitHubが音声認識による操作とコーディングを可能にする実験的機能をプレビュー公開 GitHubは、年次イベント「GitHub Universe 2022」の基調講演で、音声によるGitHubの操作やコーディングを可能にする実験的機能「Hey, GitHub!」をプレビュー公開しました。 'Hey, GitHub!' is an experiment from the GitHub Next team that aims to reduce the need for a keyboard by enabling voice-based interaction with GitHub Copilot. Sign up now to join the waitlist: https://t.co/4YOSuA6cUr — GitHub (@github
どうも、フリーランスエンジニアの人です。 今まで関わったプロジェクトにおいてコーディングルールが曖昧だった環境で苦労したので、例に出しながら振り返ろうと思います。 ※ 本記事に登場するコード例は実際に存在するコードではありませんがヤバさは忠実に再現しました。 2022/11/5 追記 曖昧かつ実態のズレた変数名 変数の命名というものはエンジニアによって少々偏った傾向が見られますが、その変数が指し示す実態と命名に大きなズレがなく、主旨が伝わればエンジニアリングにおいて大きな問題はないはずです。 ですが、世の中には曖昧かつ実態と一致しない変数名が書かれたプロダクトコードが存在します。 以下のコードをご覧ください。 ※ 今回はJSを例に出します // ユーザーのデータを取得 export const getUserData = async (id) => { const res = await
短いコードのほうが読みやすい傾向はあります。しかしながら、 短くて誤読しやすいコードよりは、長いけど誤読しないコードのほうが可読性が高いです。 今回はその話をします。 「短ければ可読性が高い」というのは勘違い 短くても可読性が低いコードはあります。例えば以下の2つの main 関数を比べてみます。 短いけど抽象化に失敗しているコード: const main = async () => { const _article = await fetch('/article'); const article = transformItem(_article); }; 長いけど分かりやすいコード: const main = async () => { const _article = await fetch('/article'); const article = { ..._article, fet
関連キーワード Google | アプリケーション開発 | プログラミング プログラミング言語「C++」は、プログラミング言語「C」から派生した。そのためC++は、Cの仕組みを受け継いでいる。C++エンジニア向けカンファレンス「CppNorth 2022」の基調講演において、「C++の成功にはCの継承が不可欠だった」と、Googleのプリンシパルソフトウェアエンジニアであるチャンドラー・カルース氏は語った。同社はC++の後継を目指して、プログラミング言語「Carbon」(Carbon Language)の開発を進めている。 CからC++への移行は比較的スムーズに進んだ。一方でC++が抱える“ある問題”が顕在化した。 C++が“使ってはいけない”と言われるのはなぜ? 併せて読みたいお薦め記事 連載:「Carbon」は「C++」の後継になり得るか 第1回:プログラミング言語「C++」が嫌われる
木瓜丸です。 最近になって、やっとNext.jsを上手く使いこなせてるんじゃないか?!と思えるようなコンポーネントの設計手法を見つけたので、Zennにまとめてみたいなと思います。 この記事で触れること この記事では、主にページ単位でどのように状態管理を行うのかに焦点を当てることにします。 コンポーネントの管理の仕方などは特に着目しませんがご了承下さい。 hooksの導入 React初心者の方は最初に疑問に思うと思いますので、hooksについて触れておきます。 hooksというのは、Reactによって提供されているuseState, useEffectといったやつや、それらを組み合わせて作ったオレオレ状態管理基盤の総称です。 この記事で用いる基本的なhooksをいくつか紹介します。 useState その名の通り、状態を持つ変数を作ってくれます。 const Hoge = () => { c
はじめに:この記事を書いた動機 これらの素晴らしい先行記事を見て、「言語学を用いれば、共通点を見つけ出して一般化・大項目化したり、取り違えやすいエッジケースを明確化できるんじゃないか?」と思ったことが、この記事を書き始めたきっかけになります。 1章は3つの主要なパターンとその詳細・例外、2章はそれらに関する文法的な解説になっています。 構造化・体系化が必要な理由 太郎くんと花子さんが英作文の問題を解いています。 次の日本語を英文に訳せ。 (1) 彼女は楽しい人だ。彼女といると退屈することがない。彼女はいつも新しいことに挑戦して…… 太郎くん(『楽しい』って英語で何やったっけ……) 狩井先生@ 1年6月「exciting は楽しいって意味やで~」 ~~ 月日が流れる ~~ 柱鈴先生@ 2年4月「excited は楽しいって意味やで~」 太郎くん(……って教わったけど、exciting か e
確かに、パッと見で 「なんだこれ?」 になりますね。 意味のないコメントとして else 句ごと削除してしまって良さそうにみえます。 しかし、実はこの「何もしない」コードは、 プログラミング(理論)的に面白い側面を持っている ので、簡単に記事にまとめてみたいと思います(記事中では Swift に似た擬似コードを使用します)。 キーワード if 式、網羅的パターンマッチ、参照透過、副作用、モナドと単位元 else 句が省略できる条件 例えば、次のコード例を考えてみます: let array: Array<Int> = ... var positiveArray: Array<Int> = [] // var = 可変変数 for x in array { if x > 0 { positiveArray.append(x) } else { // 何もしない } } ここでは array か
この記事の狙い この記事は、端的に言えば この図が言わんとしていることを理解できるようになるための解説を目指しています。 昨今のプログラミング環境において、メモリの管理方法やその実態は、詳細を知らずとも目的を達成できるようになっています。といっても、実際にはメモリは無尽蔵に使えません。制約が厳しい環境下で動かさねばならないプログラムもありますし、多少潤沢に使える環境であっても、無駄に浪費するよりは、必要最低限のメモリで効率よく動作するプログラムの方が、多くの場面においては良いプログラムと言えるでしょう。 メモリのことなど知らなくてもプログラムを書けるのは一つの理想ではありますが、現実的にはその裏に隠されている(抽象化されている)仕組みを知っておいたほうが有利です。また、昨今のレトロゲームにおけるタイムアタックで駆使されるメモリ書き換えのテクニックなども、何故そういったことが可能なのかを知る
2021/12/20追記 指摘されて気づいてしまいましたが、間違ってますね... 以前スライドを書いた時に全然気づいていませんでした 反省のために消さずに、取り消して残しておきます 「年齢計算ニ関スル法律」という法律がある。 明治三十五年法律第五十号(年齢計算ニ関スル法律) | e-Gov法令検索 とても短い法律で条文は3つしかない。 ① 年齢ハ出生ノ日ヨリ之ヲ起算ス ② 民法第百四十三条ノ規定ハ年齢ノ計算ニ之ヲ準用ス ③ 明治六年第三十六号布告ハ之ヲ廃止ス ポイントは①で、生まれた日から起算するので法律上は1年が経過した時に1つ歳を取ることになる。つまり、誕生日の前の日の24時に年齢が加算されるので、日単位でみると誕生日の前の日にもう年齢は進んでいる、ということになる。 同じ年の4月2日生まれの人と、4月1日生まれの人とでは小学校に入学する年度が違う、というのはよく聞く話だと思う。 この
株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575
TypeScriptは近年JavaScriptに代わってWebフロントエンド開発で利用されているプログラミング言語です。TypeScriptは開発生産性および開発者体験に優れていることから、開発現場で広く採用されています。TypeScriptを学ぶことは、今後のWebフロントエンド開発では、ほぼ必須といって良いでしょう。この記事ではTypeScriptを使うメリット、ならびに「TypeScript Deep Dive 日本語版」を活用してTypeScriptを短期間で学習する方法を紹介します。 はじめに 筆者はSIer出身のITエンジニアです。ゲーム開発会社などを経由して現在は一般企業でエンジニアとして勤務しています。はじめてTypeScriptの重要さを知ったのは、2018年ごろに「TypeScript Deep Dive」を読んだときでした。そして、今後必ず多くの人に役立つと考え、オリ
全体的な事を言えば、自分は書き直し反対派と思う。 morritaさんの言う20年前の意見をほぼそのまま現代まで持っている。 頭の硬い古い老人という事だろう。 そういう訳で、そんな古い側の人間が書き直しについてどんな事を思っているのかを書いてみたい。 失敗するケースは割と限定されている ソフトウェアの書き直しには、成功するものと失敗するものがある。 失敗する条件を厳密に挙げるのは難しいけれど、失敗する書き直しは、自分は見れば分かる、と思っている(本当に分かるかは議論の余地があるけれど)。 まずshinhさんの言っている半分素人が挑戦するケースは良く見かける。これはまぁいい。全然良く無いけれど。 それ以外で良く失敗するのは、ある程度の規模、だいたい10万行以上のソフトウェアで、 その時点で多くのユーザーを持っていて、 書き直しにかなりの時間と人がかかる奴が多いと思う。 そしてデスクトップ、iO
バックスラッシュ\を入力する時に円記号¥に文字化けが起きる理由 プログラムのソースプログラムは(LaTeXのソースファイルやWebページのHTMLファイル等と同様に)テキストファイル(教科書ではテキスト形式と呼ばれています。プレーンテキスト(plain text)とも呼ばれることがあります)というファイル形式で書かれます。このテキストファイルはどのようなOSでも必ずサポートされている最も基本的なファイル形式であり、実体は1バイトを単位として文字コードで表現されたデータが先頭から順に並んでいるだけのファイルです。 その文字コードは歴史的にはさまざまなものがありましたが、次第にアメリカで定められたASCIIコードが主流になり、世界中で使われるようになりました。これが国際的な規格になったものがISO/IEC 646です。これらは7ビットの文字コードなので2の7乗つまり128種類の文字が表現でき、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く