コードリーディングのコツは極力コードを読まないこと｜牛尾 剛
私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど
プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生：DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
GAFAコーディング面接こんな感じでした - yambe2002’s diary
このあいだ、GAFA数社のコーディング面接を受けて全落ちしました。後続のため、オンサイト面接がこんな感じだったよ、というのをストーリー風に仕立てて公開します。問題と会話はダミーですが、雰囲気はかなり近くできたと思います。なお実際の会話はすべて英語で、バーチャルでの実施でした。 メイン問題はLeetCodeのNo.1472をもとに作成。 https://leetcode.com/contest/weekly-contest-192/problems/design-browser-history/ ちなみに「ぼく」はIQ+30くらいの設定です。それではどうぞ。 入室と自己紹介 面接官「やあ！わたしはシンディ。会えて嬉しいよ！」 ぼく「こんにちは、シンディ。ぼくはyambe2002。調子はどう？」 面「超いい感じだよ。きみは？」 ぼ「ぼくも超いい感じさ」 面「それはよかった。わたしは部署Aのソフ
AtCoder に登録したら次にやること ～ これだけ解けば十分闘える！過去問精選 10 問 ～ - Qiita
本記事を終えた次は？ AtCoder Beginners Selection を終えたら、AtCoder 上の過去問が AtCoder Problems に集大成されていますので、片っ端から埋めるような気持ちで精進していきましょう。本記事の続編として AtCoder 版！蟻本 (初級編) AtCoder 版！蟻本 (中級編) AtCoder 版！蟻本 (上級編) AtCoder 版！蟻本 (発展的トピック編) も執筆しましたので参考にしていただけたらと思います。また、アルゴリズムとデータ構造に関するトピックを集大成した書籍として、 問題解決力を鍛える！アルゴリズムとデータ構造 (通称、けんちょん本) を上梓しました。ぜひ読んでみてください。 1. AtCoder とは AtCoder は以下のコンテストサイトを運営しています。今後常に訪れることになるサイトです: AtCoder コンテスト
【転職エントリ】Googleに入社します｜Lillian
はじめに この記事には、Googleのオンサイト面接に向けて勉強した内容が記載されていますが、それらはすべて面接を受ける直前に書いておいたものです。このエントリを読むことで面接で聞かれた内容が予測されてしまわないようにそのようにさせていただきました。ご了承お願いします。 この記事について 令和元年に医師を退職し、ソフトウェアエンジニアに転職します。 自分にとって大きな転機であったのと、とても大変な道のりであったので、私という人間が辿った道筋を最初から最後までちゃんとまとめておきたいと思いこの記事を書くことにしました。 私のような他業種から未経験での転職を目指されている方にとっても、何らかの参考になる内容であれば幸いです。 私の生い立ち 私は小さい頃からテレビゲームが大好きで、学校から帰るとずっと家でゲームをしている子でした。あまりにもゲームが好きだったので、遊ぶだけではなく自分で作ってみた
コンピューティングの基礎と高速化入門
コンピューティングの基礎と処理の高速化入門 #1 at connpass で発表したスライドです。 https://liberal-arts-for-tech.connpass.com/event/123273/
シリコンバレーで高い給料の職につくにはどの程度プログラミングできたらいいのか？ : 酒井潤公式ブログ
天才プログラマーの中の天才の中の天才であるPython言語作ったスーパー天才な人とかGoogleにいた時にほとんど働かないで年収2億円以上だったなんて話も聞いたことあります。そこまでいくと高級弁護士のアドバイザー見たんなもんでしょうね。 流石にそんな天才は日本にも少数ですが、日本でも優秀プログラマーはたくさんいますよね。だから、日本で優秀なプログラマーは、英語とビザの問題さえなければ、十分に世界で高級な給料はもらえます。 なぜ能力が同じなのにアメリカと日本の給料がこんなにも差がでるかという話は、小一時間ほど話すのにかかるのでYoutubeのこちらでも見てください。。。世の中というのは不公平であり、同じ努力をしても、結果が異なることは多いのです。 シリコンバレーの全てのエンジニアが天才ばかりではないのです。みんな給料が高いエンジニアは優秀だと思ってると思うのですが、違うんですよ。お金がある企
中学生ハルキのエンジニア体験記 - Money Forward Developers Blog
こんにちは。ハルキです。 4月から中学二年生になりました。 僕はこの春休み、パパが働いているマネーフォワードに職業体験インターンという形でお世話になりました。 プログラミングを始めたきっかけは、Scratchという子供向けのプログラミング学習サービスです。 小学校3年生の時にどハマりし、そこから6年生まで夢中になってやり込みました。 ただ、やはり子供向けなので最低限のことしかできず卒業。 その頃、マネーフォワードの方が開催してくれたバーベキューで酒井さんと出会い、そこでPythonを教わりました。 （酒井さんはビジネスマンなのにプログラミングもできちゃうすごい人なのです！） そこから、Chatworkで酒井さんとコミュニケーションを取るようになり、プログラミングで悩んだことがあったら酒井さんに報告して、バグがあれば直し方を教わるようになりました。 酒井さんは面白い記事を紹介してくれたり、そ
俺のlsが遅すぎる - Qiita
なぜ？ 必要に迫られてオレオレなlsを書いたのだがなぜか遅い。大したことしていないのに遅い。 コード 特に変なところはないと思うのだけど... #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <dirent.h> #include <pwd.h> int main(int argc, char** argv) { char fpath[PATH_MAX]; DIR* dir; struct dirent* dp; struct stat st; struct passwd *pw; char *dpath; dpath = (argc != 2) ? "." : argv[1]; dir = opendir(dpath); while ((dp = readd
無責任な"not for me"発言は迷惑なのでやめてほしい - lacolaco
愚痴。 最近特定の技術やライブラリ、ツールなどに対して、「自分には合わなかった」のような発言をする人をよく見かける。 ちょっと前だと「○○はクソ」のような直接的なdisが目立っていた気がするので、少しは丸くなったつもりなのかもしれないが、 Angularというひとつの技術のユーザーコミュニティを主催する僕としては余計に迷惑だ。 もっと慎重になれ medium.com AirbnbがReact Nativeを使うのをやめた記事、これは本当に偉い。 技術選定を行い、結果的にマッチしなかった、というレポートには、最低限次の項目が必要だと考えている。 開発の目的 選定理由 マッチしなかった理由 このどれが欠けてもいけない。単に言葉遣いが柔らかいだけでdisと変わりないどころか、下手するとFUDにすらなり得る。 FUD - Wikipedia FUD（英: Fear, Uncertainty and
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
フルタイムのコミッターとして企業に属しながらオープンソースのプログラミング言語を開発するということ - GeekOutコラム
卜部という名前で、マネーフォワードという会社でプログラミング言語Rubyの開発に携わっているものです。 実は、この文章を書き始めるまでにずいぶんと悩みました。というのも、これまでこのコラムに登場した他の人たちと違って、自分のキャリアというのは決して戦略的に積み重ねてきたものではないのです。そもそも初回の転職からして、やりたくて転職したわけではない。 思い返せば大学院から最初に就職した会社は、受託開発で忙しいながらも楽しく、社会人としてもプログラマとしても大きく成長させてくれた職場でした。何もなければそのまま一生そこで勤めて終わる、本当にそう思っていましたし、今でもやがては戻れたらいいなあと思います。しかし現実にはそうはならなかった。どこに行っても仕事がなく、開発者が余ってしょうがないみたいな時代があり、それが十年近く前ですけど、ありていに言えば放り出されてしまった。会社都合退職です。 しょ
サンフランシスコで創業したスタートアップを解散した話｜さっそ
どうも、さっそ (@satorusasozaki) です。 ぼくは「シリコンバレーで世界を変えるプロダクト作る！」という目標を掲げ、3年前に渡米しました。最初の2年間はエンジニアとして活動し、3年目に現地で出会った4人の仲間とスタートアップを始めました。1年少し続けたのですが解散することになったので、今日は以下の3点を中心に、振り返りを書いてみたいと思います。 ・シリコンバレーで現地の人とスタートアップを創業するまで ・スタートアップな生活 ・スタートアップが解散する理由 シリコンバレーで現地の人とスタートアップをするのはどんな感じなのか、できるだけ具体的に想像していただけるように、私生活など、仕事以外のことも織り交ぜながら書いていきたいと思います。これからサンフランシスコ・シリコンバレーに来て何かやってみたいという人のお役に立てれば嬉しいです。 ・・・ スタートアップを始めるまで最初に、
プログラミングにおける不安と学びのプロセス - 人間とウェブの未来
僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kyoto University Research Information Repository: プログラミング演習 Python 2019
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
プログラマーとして長く経験をつんでいても、コーディングの質が高くないプログラマーがいるのはなぜですか？どんなところが難しいのでしょうか？
