「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。

「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。
まともな文章にしたいのだけど、そうする余力がないので、記録のために箇条書きでメモ書きを残します。独学でRuby (on Rails)を学ぶために、まず初学者向けのまともな情報が少ないし、僕以上の事例はそういないと調べて思ったのと(自分で言ってすみません)、これから学ぶ人が増えるだろうから、その参考になればとも。 2015年5月20日 追記 → ※採用できたため募集終了。ありがとうございました。 開発メンバーを募集しています。意欲と能力を兼ね備えた若者を歓迎します。スキルは、この記事を書いた当時の僕くらいあればokです。 30ruby.hatenablog.com 2017年11月23日 追記 フロントエンジニアを募集します!やる気があって、実務経験あって、EdTechの本命として教育を根本から変えていくというミッションに共感していっしょに走ってくれる方を探してます! www.wantedl
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ
Photo by Joi 今回のpaiza開発日誌は片山がお送りします。 今後も技術(開発)を中心にエンジニアとしてのキャリアを歩んでいきたいなと考えている方向けに最近騒がれているフルスタックエンジニアとは何か、という事と、何故今後フルスタックエンジニアしか生き残っていけないのか?という事について書いてみました。 ■最近よく見かける【フルスタックエンジニア】とは何か? まずStackって何だろう?、というところで海外の記事などを読むと"LAMP stack"という言葉が良く出てきます。LAMPの場合、OSはLinux、WebサーバはApache、データベースはMySQL、プログラミング言語はPHP(もしくはPerl、Python)という形で組み合わせたものの事を言います。つまりOS、Webサーバ、DB、プログラミング言語の組み合わせ≒積み重ね、なのでStackという事のようです。こういった
お馴染みのCoding Horrorでプログラミングの隠語(ジャーゴン)についての記事が話題です。 このエントリの元になったのはStack Overflow上で行われた「あなたが新しく作ったプログラミングのジャーゴンはなんですか?(New programming jargon you coined?)」という質問です。この質問にはなんと386もの回答が寄せられ、その中でStack Overflowのコミュニティの投票で上位になった30のジャーゴンをリストにして解説したのがCoding Horrorの「Coding Horror: New Programming Jargon」という記事です。 下記がコミュニティによって選ばれたジャーゴンのリストです。 1. Yoda Conditions(ヨーダ条件式) 変数とリテラルを比較する際にリテラルを左辺に置く記述。スターウォーズのヨーダが「The
話の発端は 先日公開された FC2 ソースへの感想から。 http://opensource.slashdot.jp/story/14/03/24/0937246/FC2%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AE%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%8C%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E5%8C%96%E3%81%95%E3%82%8C%E3%82%8B isExistメソッドとか (スコア:1) by Anonymous Coward on 2014年03月25日 10時54分 (#2568810) もろに日本人っぽいソースコードで好感が持てる。
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます #9:優れたコミュニケーションスキル 「コミュニケーションスキル」といっても、「完璧な国語を話す」という意味ではない。これは「考えを正確に、かつ効率良く伝えることができる」ということを意味しているのである。図面や音声、ジェスチャーはすべてコミュニケーションスキルを構成するものである。自らの言いたいことを相手に伝える、あるいは理解してもらうことが苦手なプログラマーは、長い目で見れば効率的に仕事をこなせないということなのである。これは、電話による面接では的確に評価することが難しい能力であるのものの、対面の面接でうまくコミュニケーションができなければ、仕事でも苦戦することになるのは間違いないはずだ。 #10:上司をたてられるか? プログラマー
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
私は色んなプログラミング言語を触るのが病的*1に好きで、どの言語をどういう場面で使うのが良いのか凄く興味があります。 そこで、今の私の知識範囲でのそれぞれのプログラミング言語の使いどころを(自分用の整理もかねて)書いてみます。 C/C++ - C=OSやミドルウェア、C++=効率化のための再実装 安直に「メモリとスピードが第一優先のとき」と思いたいところですが、同等程度のスピードでもっといい言語はいっぱいあります。計算集約的ならJuliaとか、オブジェクト指向で組むようなソフトならD言語とか。なのでまずC言語は、Swigみたいのを使って他の言語の拡張ライブラリを書いたり、システムコールを使ってOSやミドルウェアを書くときじゃないかと思います。C++はテンプレートを駆使したりして効率を維持しながら抽象度の高いコーディングをするような場面がしっくり来ると思います。既に他の言語で実装したソフトウ
すまん。タイトルは釣りだ。 プログラマーにとっての技術力というのを、プログラミング言語やツールを使って問題を解決する能力だとすると、実はそれは優秀なハッカーであるための十分条件ではない。 優秀なハッカーであるためには、高い技術力を持つだけではなくて、問題を発見するという能力が必要だ。オープンソースの世界で活躍している著名なハッカーたちに共通することは何か。それは「だれも問題にしていなかったことを問題だととらえ、それを解決するためのツールを作っている」ということだ。彼らが publish するライブラリは、いままで、誰も問題にしてなかったからこそ今まで存在していなかったわけだ。それを問題だととらえる、言って見れば問題発見能力こそが優秀なハッカーになるための条件なのだ。 技術力なんて、勉強すればいくらでもあとからついてくる。というか、自分の技術力を磨くのはプログラマーとして当然のことだ。それさ
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
Webサービスを作りきる気力がなくなってきてるなーって感じてしまった。 これはヤバいと思って、なんでこうなったのか考えてるといろんなことを思った。 サービスを作るのってすごく気力が必要で、まずどんなサービスを作るのか考えないといけないし、どういう見た目にするのかも考えないといけない。 考えてみると僕は普段から「こんなサービスを作りたい」とか「今どんなサービスが刺さるのか」とか「このサービスはデザインがイケてる」とか考えるタイプではない。 大学で情報系の学科にいて、遊び呆けて3年の頃には全然授業がわからなくなった。 他の大学ではどうなのかわからないが、情報系の学科ではプログラミングができる人はできない人から見ると、回りから頼られるしものすごい人に見える。そして自分もそうなりたいと思ってプログラミングの勉強を始めた。 僕のいる学科ではプログラミングは何かを作るための手段でしかなく、何を作るのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く