45歳プログラマーさん、警察庁とNTTとSMBCのソースコードを世界に無償公開してしまう
プログラマー歴20年の艦これ提督が 作ったプログラムを入れると年収を査定してくれるからと 手持ちのプログラムを全て入れてしまい SMBCとNTTと警察庁、日銀、埼玉県庁で使っているソースコードGithubで世界中に公開してしまう
プログラマー歴20年の艦これ提督が 作ったプログラムを入れると年収を査定してくれるからと 手持ちのプログラムを全て入れてしまい SMBCとNTTと警察庁、日銀、埼玉県庁で使っているソースコードGithubで世界中に公開してしまう
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。
フリーで使えるプロジェクト管理ツールをまとめておきます。 ■ガントチャート 開発マイルストーン ガントチャートでプロジェクト管理できるExcelツール フリーとは思えないほど高機能 ガントチャートforExcel・・・シェアウェアになりました こちらもガントチャートでプロジェクト管理できるExcelツール スケジュールの表示期間を切り替えられるのが便利 OpenProj Java ベースでガントチャートでプロジェクト管理ができるツール Microsoft Project のフリーのビューワーとしても利用可能 フリーの高機能プロジェクト管理ソフト「OpenProj」を試してみました TaskLine Excelのアドインとして動作するプロジェクト管理ツール（saramiさん情報） Microsoft Projectのファイル(XML形式)をExcelで表示するProjectViewerもある
プログラミングでよく使う英単語のまとめ【随時更新】 随時追加、整理していきます。 名前をつけるときには、名詞、動詞の違い、複数形、過去形などに注意しましょう。 オブジェクト指向では、クラス名は名詞、メソッドは動詞とします。 使ってはいけない言葉 get / set アクセサ (getter / setter) やプロパティによく使われている。 それ以外に使うと混乱を招くのでよくない。 get は軽量な処理と考えるので、中に重い処理は書いてはいけない。 単純な取得/設定以外で使いたくなったら他の言葉を考える。 load, save, commit, store, enable, disable, fetch, register, configure, add, etc... check 意味が広すぎて何をしているかわからない。 できるだけ別の言葉を使う。 具体的に何をしているかに分解して考え
俺はさっきまで知らなかった。これはやばすぎるので増田に書いて広めようと思う。（追記にも書いたが、公式の英語字幕があるので聞き取れなくても心配しないでほしい。） 以下のリンクから飛べる。 https://nptel.ac.in/courses リンク先を見ればすぐ分かると思うが、驚くべきは、カバーしている分野の広さだ。アメリカのMOOC(Udacityだの、Udemyだの)は、表層的な、「すぐ使える技術」の講座ばかりで、オペレーティングシステムやコンピュータネットワーク、あるいは偏微分方程式や代数学といった、コンピュータサイエンスや数学等の基礎学問のような分野はあまりカバーされていない。（主観だが、恐らく正しいはずだ。Udacityのジョージア工科大のコンピュータサイエンスの授業は別だが、数は少ないし、それにしても数学はカバーしていない。） しかし、この「NPTEL」では、自分に関わりのある
2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日本に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い
インフラについて、何となく理解しているつもりでも、「インフラとは何か？」と聞かれると、こういうものであると明確に答えるのは案外難しいものです。 そこで、インフラの基礎がわかるスライドシェアを10個ピックアップしてご紹介します。 インフラエンジニアの定義、インフラの基礎、手順書の書き方、インフラ自動化など、初心者から中級者向けの内容となっています。 Web業界で働くなら、システムの基盤となるインフラについて学んでおいて損はないはずです。
ネットをきっかけに世の中が動いた、2016年「はてなブックマーク年間ランキング」 今年を象徴する話題が続々 - はてなニュース
2016年は、インターネットをきっかけに、世の中の動きにも影響を与えるような話題が次々と生まれた1年でした。今年を象徴する話題から何度でも読み返したい名文まで、2016年のはてなブックマーク年間ランキング上位100エントリーを発表します。（集計期間：2015年12月11日～2016年12月10日） 2016年 はてなブックマーク年間ランキング（2015年12月11日～2016年12月10日） 順位 タイトル 1位 PCデポ 高額解除料問題 大炎上の経緯とその背景(ヨッピー) - 個人 - Yahoo!ニュース 2位 京大院生の書店スタッフが「正直、これ読んだら人生狂っちゃうよね」と思う本ベスト20を選んでみた。 ≪リーディング・ハイ≫ - 天狼院書店 3位 夏休みの宿題進捗管理をIT化してみたら子どもが凄くやる気出したので今年もやろうかな、という話 | Books&Apps 4位 炎上中の
新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて（元エントリでは学生さんのようである。さもありなん）そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった？」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
# 数億円規模のプロジェクトをたった二人で開発させられた話 先日、関わっていたプロジェクトを抜けることになりました。 原因はもちろん炎上によるものなんですが、これがもう炎上すべくして炎上したようなぶっ飛んだプロジェクトでしたので、 ここで吐き出させて下さい。 # 20数名のメンバーの一人だったはずが、いつの間にか総勢一人になっていた 僕の仕事のスケジュールに空きができ、週３日程度の仕事を探していた頃、Twitterから開発案件の依頼がきた。 内容はよくあるシステムのリプレース案件。 開発メンバーは既に５人程度集まっており、その後２０人ほど合流するとのことで、総勢２０名以上の開発メンバープロジェクトだ！こんな規模の新規開発なんて初めてだからワクワクするぞ！ と思っていたら、PHPの案件なのにほとんどがJavaの人だったのでメンバーとして数えられず、参画する前に去っていってしまった。 合流する
Twitterでは定期的に読んだ本を紹介している。 そこでnoteでも2020年のIT業界で働く方々におすすめしたい本をまとめてみた。 Twitterや他のnoteはふざけた内容だが、マスク・ド・アナライズの運営方針は「書評だけはガチ」である（ノアファンではないが）。 ここ1年で読んだ中で「役に立つ」「面白い」「仕事に活かせる」「ITに関わる人間に読んでほしい」と思った本であることを保証する。 書評の後にAmazonリンクもあるので、役に立たないAI・データサイエンス本にエサを与えずに、きちんとした書籍にお金を出すことで出版業界に貢献してほしい。 ここからオススメの10冊紹介する。 追記：アフィリエイト貼るのを忘れたので思う存分クリックしてください。 誰が音楽をタダにした音楽業界におけるMP3の誕生というテクノロジー視点、違法アップロードするアングラサイト運営者の視点、既存のCD販売を手掛
Twitter：https://twitter.com/Nunerm Roppongi Product Manager Meetup #6 のLTで発表した資料 https://pm-roppongi.connpass.com/event/99971/ Read less
プログラマーを30年間やってきた経験から学んだことまとめ
プログラマーにとって「どうすればより効率よくプログラムを組み上げられるのか」は常に頭を悩まし続ける問題の1つとなっていますが、その道のエキスパートであるエンジニアのジュリオ・ビアソンさんが30年間ソフトウェア開発に携わってきた経験から学んだことについてブログにまとめています。 Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development) https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/ ビアソンさんは多数ある「学んだこと」を以下の3つに大きくわけてまとめています。 ◆ソフトウェア開発について ◆チーム・仕事について ◆個人的なことについて これからプログラマーになろうとしている、あるいは
この１〜２年、転職であったり起業であったり人の動きが激しいような気がします。私の知人も、大手企業でエリートだったのに起業したり、大手メーカーからソーシャルゲームの会社に転職したりしています。そうした人たちを見ていて、人の働く動機には色々ある中で、いくつかパターンがあるのかなと思い、人は何のために働くのかについて考えてみました。 ※この記事は、2011年07月07日に公開された記事を再編集したものです。 モチベーション４つのパターン 私なりに人が働くモチベーションとして、以下の４つのパターンがあるのではないかと考えてみました。（これは私の知り合いからの類推なので、専門的で正確な話ではありません） ・「アントレプレナー」タイプ ・「クラフトマン」タイプ ・「サラリーマン」タイプ ・「サポーター」タイプ アントレプレナータイプの方にとっての仕事に対する動機は「夢」が大きく影響しているように思いま
2011年も残すところあと少しになりました。2011年にはてなブックマークをたくさん集めた記事の中から、Webデベロッパー向けに限定して厳選してお届けします。 ウェブデザイン入門 ウェブサイトにおける視覚面に対し、整理・再構築・意匠等を施す。グラフィックデザイン的な要素を多く含む一方で、インタラクティブな要素を持つウェブの性格上、情報デザインあるいは工業デザイン的なスキルも求められる。ウェブサイト全体の情報設計、見た目を中心とするグラフィックデザインやGUIの設計、ウェブアプリケーションのUI設計構築など多岐に渡る。 Web制作をこれから始める人の為のスキル・HTML・CSS・ブラウザ・写真素材入手の基礎情報 WEBデザイナーを目指す人へお勧めしたい記事・サイトまとめ – YATのBlog デザイナーからデザインの基礎や原則を学べるエントリーまとめ（webデザイナ向け）*ホームページを
codepad
codepad is an online compiler/interpreter, and a simple collaboration tool. Paste your code below, and codepad will run it and give you a short URL you can use to share it in chat or email. Language: C C++ D Haskell Lua OCaml PHP Perl Plain Text Python Ruby Scheme Tcl
技術に精通した コンサルタント が併走 経験豊富なアドバイザー 元ITエンジニア、元ゲーム企業人事、 IT会社役員、大手人材エージェント
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
を具体的に書いてみる。 まず最初にニートがやるべきことは、「このゲームは、正攻法でやるかぎり、どう足掻いても、絶対にニートが勝つことができないように仕組まれた八百長ゲームである」ことに気づくことだと思う。 だから、正攻法はだめだ。明後日の方角から、とんでもない反則攻撃をして、八百長ゲームのルールを食い破って勝利を強奪するような戦略で行くべきだ。 具体的にいうと、まず、そもそも、正面玄関から企業に就職面接を受けにいくのはやめとくべきだと思う。 ニートの場合、「この空白期間はなに?」とか聞かれて撃沈するだけ。時間の無駄な気がする。 職歴が弱点なんだから、その弱点を突かれるような戦いかたをしてどうする、というか。 その弱点を無効化するような戦い方をするべき。 で、職歴という弱点を無効化するために、ダンピングもどきの反則技を使う。 ほんもののダンピングは、独占禁止法で禁止されている。それだけ悪質で
56歳からコードを書き始めて食べていく方法
私は56歳、最近プログラミングを始めたんだ。 なぜかって？やりたいからに決まっているじゃないか。ようやく最近コツをつかめてきてね。でもコツをつかめたからといって簡単にはいかない。正直なかなか手こずっている。でもいいんだ。 アルゴリズムに挑戦して我を忘れるのは楽しいし、まだテストしたい事があって「あと数分だけ」と繰り返し自分に言い聞かせるのもいい。「今度こそ上手くいったかも、、」とドキドキしてから「やったぞ！ついに動いた。」となる瞬間も大好きだ。 でもこんな私には今まで趣味と呼べるものが何ひとつなかった。自分に見返りがない事に時間を費やすのは嫌だったんだ。ただ楽しみのためだけに何かをするのが好きじゃなかったのさ。休みの日にやる事といったら、ちょっとした小遣い稼ぎになるような事ばかりだった。 オーケー。もちろんコーディングだって小遣い稼ぎさ。上手くやればかなり稼げる。これだってあなたから見れば
強いエンジニアになるために英語が必要と聞いたので４ヶ月でTOEICスコア400→900まで上げた話 - Qiita
はじめに 初投稿です。 筆者スペック 19歳 高卒 某大手自動車メーカー関連会社勤務 エンジニア志望 (Web開発勉強中) 業務の効率化（データ整理・画像処理など）でPythonを書くことがあります。Python歴は半年程度です。 英語学習について、 どのように学習してきたのか記録を残すため 「TOEICのスコアを伸ばしたい」と考える方にとって少しでも参考になれば と思い、記事を書くことにしました。 英語学習の動機 「エンジニアには英語が必要」 論 エンジニア/エンジニアになりたい方なら、1度は「エンジニアに英語は必要か」という議論を目にしたことがあるのではないでしょうか。 自分は現在エンジニアになることを志しています。 そのための情報収集をしていると、「エンジニアに英語は必要なのか？」という主旨の記事、議論を時折見かけます。 そして、その結論は殆どの場合「強いエンジニアになりたい場合、あ
はじめに さいきんのWebはSPA技術を中心としたフロントエンドが賑わっていますね💪 従来サーバーサイドを扱っていた人もフロントを触る機会が増えていたり、これからプログラミングを学んでいく人も、フロントエンド領域に興味を持っているのではと思います。 そこで、フロントエンドの経験が浅い方や初学者向けに、おすすめのドキュメントや勉強すべき領域をまとめました。 とりあえず動けば良い段階から一歩進んで、フロントエンドエンジニアとして、良いアプリケーションを作るために必要な知識を浅く広く紹介します。 ※補足 新米と表記しましたが、実際には新卒や未経験でなく、新卒2~3年目の若手フロントエンドエンジニアやフロント分野に苦手意識のあるバックエンドエンジニアの方を対象としています。 数日で目を通せるような内容ではないため、マイルストーンやスキルセットの一つの参考にして頂けると幸いです。 フロントエンド入
35歳を超えたエンジニアの5つの働き方
おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 ぼくは36歳です。けっこう大きなサイトで、RailsやJavascriptを書いたり、パフォーマンス改善したり、iPhoneアプリの開発でObjective-Cを書いたりしています。マネージメントはしていなくて、今でも普通にエンジニアとして働いています。 35歳定年説の35歳を超えてから1年以上が過ぎたところですが、昔のようにはいかなくなってきたところ、昔と変わらないところ、昔よりよくなってきたところなどがいろいろあります。年を取ってもエンジニアを続けたい人の参考になるかどうかわかりませんが、そういう人たちのためにぼく個人の体験をここに書いておこうと思います。 1.理解できるまで聞き返す 特に若い人たちとの会話で痛感するのですが、相手の言いたいことを一度で理解することが難しくなってきまし
すべてのプログラマが読むべき記事10選 | POSTD
Javaプログラマやソフトウェア開発者として、私は「プログラマが知っておくべき…」というタイトルが付く記事から、多くのことを学びました。そういった記事は、特定のトピックに関する有益かつ詳細な情報を数多く与えてくれましたが、探し出すのが非常に困難でもあったのです。知識を探求する中でとても役に立つ記事を見つけたら、参考として何度も読み返せるようにブックマークしてきました。こういった記事を読むことは、どのプログラマにとっても有益になると思うので、私が集めた「 すべてのプログラマが知っておくべきこと 」を皆さんと共有する為にこれを書きました。 ここで紹介する記事は私が個人的にブックマークしたものです。「メモリ」、「Unicode」、「浮動小数点演算」、「ネットワーキング」、「オブジェクト指向設計」、「時刻」、「URLエンコード」、「文字列」などといった代表的なトピックについて載っています。このリス
ここでは主導する方が知っておくべきものをまとめています。 なおこの記事での 1on1 とは、バスケのハーフコートにおける 1 対 1 の攻防ではなく、職場における 1 対 1 の定期的な話し合いのことです。 1on1 で話すべきこと 業務以外の課題解決 なにか課題を抱えていると他のどの話題にも身が入らないため、まず話せる環境を作りましょう。同様に課題は業務効率を落とします。 ここでの課題は次を指しています。 健康上の課題 業務が原因で病院受診が難しい場合の業務量の調整など お互いの健康テクニックの共有なども Good 家族との課題 お子さんが夜泣きで寝不足などの場合は就業時間の調整など 親族と折り合いが悪いなどの場合、第三者としての意見や、自分の経験を共有する 社会上の課題 コロナ禍によるつらみの共有など 業務に連動するわけではないため、前回課題がなかったからといって今回もないと仮定しては
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
人月計算とExcelとスーツの世界より
俺の住む世界はアイティーとやらに支えられているらしい。 アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。 そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。 昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。 だから自分はシステム会社に向いていると思った。 実際、資格取得を勧められて始めた勉強は楽しかった。 浮動小数点数、オートマトン、SQL、スタック、木、論理式。 パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。 楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。 研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。 現場に出て、本番機に触った。 ３０年間親会社を支え続ける偉大なシステムの中身を、わくわくし
Photo by Joi 今回のpaiza開発日誌は片山がお送りします。 今後も技術（開発）を中心にエンジニアとしてのキャリアを歩んでいきたいなと考えている方向けに最近騒がれているフルスタックエンジニアとは何か、という事と、何故今後フルスタックエンジニアしか生き残っていけないのか？という事について書いてみました。 ■最近よく見かける【フルスタックエンジニア】とは何か？ まずStackって何だろう？、というところで海外の記事などを読むと"LAMP stack"という言葉が良く出てきます。LAMPの場合、OSはLinux、WebサーバはApache、データベースはMySQL、プログラミング言語はPHP(もしくはPerl、Python)という形で組み合わせたものの事を言います。つまりOS、Webサーバ、DB、プログラミング言語の組み合わせ≒積み重ね、なのでStackという事のようです。こういった
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 ソフトウェア開発では、手法やフェーズに応じて適切にツールを使い分けることが重要です。株式会社エウレカが、主力サービスのPairs開発チームで実践しているTrelloを活用したタスク管理のノウハウや考え方を紹介します。 初めまして。株式会社エウレカのCTO Office責任者、梶原成親（@kajinari）です。 エウレカが目指すのは自立・自律した組織。全社でスクラム（Scrum）開発を推進し、強いチーム作りをするのが私のミッションです。 管理ツールもさまざまに使い分けていますが、スクラムに合っていると感じるのは、タスク管理ツールのTrelloです。私はもともとアトラシアンのユーザーグループで、東京代表のオーガナイザーを務めていました。Trelloは、アトラシアンが買収したのを機に使いは
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/ Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？ A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。 それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。 Q2.なんで新規で作らないの？ A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。 Q3.メインフレーム（汎用機）って何？ A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーご
上杉周作シリコンバレーのエンジニアが語る、誰にも悪気はなかった話2017/02/22 貧困の連鎖を止めようとしたら、子どもの学力が下がりました。働き方から変えよう、地方から変えようとしたら、何も変わりませんでした。 自己紹介こんにちは。上杉周作と申します。教育について考えるのが好きな、シリコンバレー在住のエンジニアです。 88年生まれで、中学1年まで日本で暮らし、それからはアメリカ在住です。カーネギーメロン大でコンピュータサイエンスを学び、AppleとFacebookでエンジニアインターンをし、その後シリコンバレーのベンチャーを転々とし、2012年9月よりシリコンバレーの教育ベンチャー・EdSurgeに就職しました。2017年1月にはNHK「クローズアップ現代+」の教育特集に「教育×IT」の専門家としてお呼びいただき、教育評論家の尾木ママさんと共演しました。 そしてこのたび、4年とすこし働
人生は練習と思ってる所が本番で、本番と思ってる所はオマケだ。 http://d.hatena.ne.jp/teruyastar/20131207/1386476138 年末の記事に反響があったのですが、 「ずっと本番って、その努力ほんとに報われるのか？」 という意見をもらいました。 あと関連で、 ｢基礎が大事｣という本当の意味を理解しているか? http://d.hatena.ne.jp/teruyastar/20110208/1297157480 「基礎を無意識のゼロに限りなく近づけるのが守破離の守、 といっても、いつになったら破・離へ移行するの？」 みたいな意見も。 なるほど、、基礎や準備こそ大事ではあるのですが、 これは確かにやみくもな努力へのミスリードに見えるかもしれません。 そうならないよう「正しい努力の仕方」を示す記事 をまとめてみました。 前提・7つの習慣における「第2領域」
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす http://japan.internet.com/busnews/20111013/8.html で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。 （2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。 Stevey の Google プラットフォームぶっちゃけ話 僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやも
一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選 - 設計と実装の狭間で。
10万行コード読んだらJava分かるよってTwitterに書いたらすげぇ勢いでRTされたので、調子に乗って捕捉エントリ書くよ。 Java Core API JDKインストールしたディレクトリに入ってるsrc.zipを展開すると入ってるから読むと良いよ。 すぐ近くにあるのから読むってのはメンタル的に楽でいい。 厳密にはOSSじゃなくて単に公開されてるってだけなんだけども、JavaプログラマなのにコアAPIのコード読んでないとか無いよね？ どれから読めば良いか分からんかったら、 java.lang java.util java.io java.text 辺りをまずはキチンと理解すること。当然コードを読み終わったら、それを使ってコードを書く事。 OpenJDK http://hg.openjdk.java.net/jdk7/jdk7 OpenJDKを読むことで、プログラム言語してのJavaではな
「きちんと管理すれば企業は成長する」の迷信が企業を衰退させる〜ToMo指数の研究〜｜Yasuhiro Yoshizawa
事業が軌道に乗り、ここ２１ヶ月連続で、毎月売上記録を更新してきたベンチャーA社は、ついに念願の上場を迎えた。 ところがその直後、毎月の売上が急激に鈍化。役員たちは、上場初年度の売上予測の下方修正といった事態をなんとしても避けたいため、事業を担うマーケティング部長、営業部長たちに、こう檄を飛ばす。 「もっとしっかりと分析を行って、何を改善すべきかレポートにまとめてくれ。そして、速やかに改善計画を立て、実行してほしい」 今振り返れば、このときまでが、A社の繁栄のピーク。 この号令を境に、事業を担うメンバーたちは、「今月は、お客さんへのリーチを２０％回復させるためになんとかしなければ」「来訪したユーザが、うちのサイトで購入してくれる率を５％改善しよう」など、計画に基づいて打ち手を探るが、なぜか以前のようなインスピレーションも沸かなければ、ありきたりなアイデアばかりの繰り返しとなる。 一向に成長の
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あるＳＥのつぶやき: フリーで使えるプロジェクト管理ツールまとめ
プログラミングでよく使う英単語のまとめ【随時更新】
君はインド最大（多分世界最大）の無料MOOCの「NPTEL」を知っているか。
ドイツの受託開発会社を退職しました - WETな備忘録
インフラエンジニア以外も必見！インフラの基礎が学べるスライド10選-レバテック
底辺IT企業は『書けない』プログラマとどう向き合ってきたか - megamouthの葬列
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
数億円規模の案件を たった二人で開発させられた話
「Visual Studio」の中の人が作ったプログラマー向け十徳ナイフ「DevToys」／今までググって探していたツールがひとまとめに
2020年のIT業界で働く人に読んでほしい10冊｜マスクドアナライズ
心理的安全性を 0から80ぐらいに上げた話
モチベーションの源泉：何のために働くのか、転職か起業か | Social Change!
【２０１１年】【Webエンジニア向け】はてブ数ランキング厳選超人気記事総覧 / Devslog
IT業界・エンジニアの転職ならTech Stars Agent
分裂勘違い君劇場 - 無学歴、無職歴、無実力のニートが年収500万円の正社員になる方法
すべての新米フロントエンドエンジニアに読んでほしい50の資料 - Qiita
1on1 ノウハウの共有 | DevelopersIO
35歳定年説より怖いフルスタックエンジニアしか生き残れない未来とは - paiza times
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
主婦が技術書を書いてSIerに入社した話/jtf2016 - Docs.com
京都市が今回失敗したような、自治体のシステム更新について
シリコンバレーのエンジニアが語る、誰にも悪気はなかった話
もらえる経験値を最大化する「正しい努力」のまとめ - teruyastarはかく語りき
Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（前編）