半年ほど前だが、アメリカの超大手IT企業からスカウトが来て、そのくせ電話面談で落とされるという屈辱的な経験をしたので、戒めとして晒しておく。 4月下旬 LinkedIn経由でリクルーターからメッセージが届く。デトロイトで本社採用SDE(Software Development Engineer)の採用イベントがあるから、来ないか、という内容。まああの会社なら受けてもよいと思って、Resumeを送る。 ちなみに、ResumeはoDeskでフリーの方に添削してもらった。 そしたら、すぐに返答が来て数日後に電話面接が設定される。早い！準備をする時間がない！ 電話面接(一回目)、3日前まで この定石本をざっと眺める。ただし、実際のアルゴリズム質問集までやるのは無理なので、Behavioral Questionsの準備にとどめておく。 www.amazon.co.jp あとは、以下について、Wiki

(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、本当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars （忍者戦争）でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v

これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら

Level up your coding with games, puzzles, and challenges.

Javaのgetter/setterのお話。 僕は当時を語るには若すぎるのだけど、過去を振り返って書いてみる。当時を知る人は誤りがあれば指摘してほしいし、情報があればコメントなりトラックバックなりして欲しい。前世紀の話というのは今となっては探すことがなかなか難しくなりつつある。 「privateな変数にpublicなアクセサを定義する」？ - ネットの海の片隅で getter/setterとは何か Javaのオブジェクトにフィールドがあったとして、そのフィールドに値を設定するメソッドがsetter(せったー)、そのフィールドの値を取得するメソッドがgetter(げったー)と呼ばれる。慣習としてsetterはsetXXX(int value)といった様にsetから始まる名前をつけ、引数はひとつ。戻り値はvoid型。getterはgetXXX()といった様にgetから始まる名前をつけ、引数はな

このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

Javaプログラマやソフトウェア開発者として、私は「プログラマが知っておくべき…」というタイトルが付く記事から、多くのことを学びました。そういった記事は、特定のトピックに関する有益かつ詳細な情報を数多く与えてくれましたが、探し出すのが非常に困難でもあったのです。知識を探求する中でとても役に立つ記事を見つけたら、参考として何度も読み返せるようにブックマークしてきました。こういった記事を読むことは、どのプログラマにとっても有益になると思うので、私が集めた「 すべてのプログラマが知っておくべきこと 」を皆さんと共有する為にこれを書きました。 ここで紹介する記事は私が個人的にブックマークしたものです。「メモリ」、「Unicode」、「浮動小数点演算」、「ネットワーキング」、「オブジェクト指向設計」、「時刻」、「URLエンコード」、「文字列」などといった代表的なトピックについて載っています。このリス

My iPhone 11 is perfectly fine, but the new buttons on the iPhone 16 are compelling

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを

自分の書いているプログラムからNICの設定を直接弄りたくなった事はないだろうか？ プログラム内からifconfigコマンドに引数をつけて実行すれば簡単に実現できるが、それはあんまり格好良くないし、情報を取り出そうとするとifconfigコマンドの出力文字列をパースしたりしなければならなくなって格好悪い。 よりプログラムの書き方として正しいのは、ifconfigコマンドが叩いているAPIを自力で叩いてみる事だろう。 というわけで、ここではifconfigコマンドがNICを操作するために叩いているAPIを自力で叩いてNICの設定を変更してみようと思う。 まずは最も単純なプログラムとして、NICのリンクステータスをUP/DOWNするというのを試してみよう。 ソケットへのioctlによるNICリンクステータス変更 ifconfigコマンドで行われているNICリンクステータスの変更処理を最小限のコー

3. 自己紹介 1992年～1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。

"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ

Bugzillaプロジェクトの主任設計者の実体験に基づいた、ソフトウェアの簡潔性を保つさまざまな知見をまとめた書籍。「なぜ簡潔性が大事なのか」「変更の価値を計るための方程式」「コードの簡潔性と複雑性」といったトピックについて、事実、法則、ルール、定義などを示しながら解説します。直接的なコードの書き方だけでなく、ソフトウェアプロダクト全体にわたるコードの健全性を保つためのヒントとなるでしょう。なお本書はEbookのみの販売となります。 まえがき 1章　はじめに なぜ簡潔性が大事なのか ソフトウェアデザイン 2章　なぜソフトウェアを作るのか 実際のアプリケーション 3章　未来 ソフトウェアデザインの方程式 デザインの品質 見えない結末 4章　変更 プログラム変更の実例からわかること 3つの間違い インクリメンタルな開発とデザイン 5章　不具合とデザイン 故障でなければ…… 何度も同じことを繰り

最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ

昨日、@irofさんと飲みながら自分を思い返すと「ちゃんとソフトウェア開発を勉強しはじめてから3年間たった」つまり「@bleisさんを知ってからこの5月でまる3年間たった」 それまでの僕はデザインパターンもオブジェクト指向がなんたるかも、バージョン管理もなにも知らなかった。 毎日言われたことをこなす仕事をして、変えたいけど誰も教えてくれないし、学び方すら教えてくれなかった。 それなりに努力してたけど、よくはわかっていなかった。 そんな状態から抜け出したのが3年前。このブログの先頭でも書いた。当時僕は21歳かな。（ちなみに就職したのは19歳のとき） →【このブログをはじめるきっかけ - うさぎ組】 この3年間でやったことをふりかえってみようと思いました。 ちょっとわかりにくいだろうけど、2009年5月からの12ヶ月周期で書いてみます。 こうやって振り返るのはあくまで僕のためであって、何かを誇

Photo by muraterturk こういった記事って、ネーミング規則や慣習の視点から書かれていることが多いんですけど、この記事では、英文法に視点を置いて、参考になりそうなことをいくつかピックアップしてみたいと思います。 「省略形は使わない」などの規約的なものは、各プロジェクトのルールに従えばいいので、ここでは書きません。あくまで英語という視点から書いているということを、ご理解ください。 Rule 1 : “検索”は名詞 一般的な英語辞書のルールでは「検索」は、動詞ではなく「検索する」が動詞になります。「検索」は、検索することの名称 だと考えられるため、動詞ではなく名詞として扱います。 英語辞書には、日本語の品詞ごとに表記のルールがあります。これが理解できていると、和英辞書などで品詞を意識して検索できるようになります。以下に、一般的な英語辞書の表記ルールをまとめてみました。 ＜各品詞