(この記事は闇 Advent Calendar 2013 - Adventar の8日目です。) コンプレックスの話をする。 僕がプログラミングを始めたのは、2008年の夏、大学1年の夏休みだった。大学のサークルの新歓を巡ったはいいが、どこもかしこも絶望的につまらなくて、当時エンジニアとネットウォッチャーしかいなかったTwitterをみていると、彼らがとても楽しそうに見えていた。 だから僕はTwitter漬けになって、一人でプログラミングの勉強をすることにした。大学では最低限の単位を確保しつつ、とりあえずなんでもいいからアプリを作るぞと、はてブで流れてきたホットそうな技術をひたすら手につけてみた。とにかく、新しそうなものをやるという戦略だった。 最初にやったことは、ゲーム用だったWindowsのデスクトップマシンを潰して、ひたすらUbuntu8.04をインストールしては、Railsのサーバ
この記事は「Theorem Prover Advent Calendar 2013」6日目の記事です。 http://qiita.com/advent-calendar/2013/theorem_prover 神田「野らぼー」にて、地下の薄暗い店内で… 「そう言えばこないだ隣で起こってたポインタオーバーラン、対応大変そうだったですけどちゃんと家に帰れてたんでしょうかね、新婚なのに…」 「ヌルポとかポインタオーバーランとか、どうして無くならないんだろうね。その時はみんな手を抜いてるつもりなんて毛頭なくて、一生懸命考えて大丈夫だと思ってるはずなんだけどね。レビューもして、それでも起こった後でみんなでソース見てみると、なんで気づかなかったんだよ!ってことになる。」 「人間って、そういうの苦手なんでしょうねきっと。ほら、『何かほかにありませんか』って聞かれても出てこないじゃないですか。静的な解析っ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
Ruby Advent Calendar 2013 1日目Ruby Advent Calendar 2013、1日目の記事になります。 こんにちは。1日目の記事ということでかなり緊張しています。 さて、いつもネタ記事ばかり書いている私ですが、さすがに1日目ということで、入門的な内容、つまり、これからRubyを始めたい方のための記事を書いてみたいと思います。真面目に。 実は、私もRubyを使い始めてから1年も経っていないのですが、ある学習法を取り入れることで、飛躍的にRuby力を向上させることに成功しました。今回はその方法をお伝えします。 Minecraft ステップ2Minecraftで遊びます。 images by aoisensi ステップ3「そろそろマルチプレイやるかー」と言ってマルチサーバーを立てて遊びます。 photos by sixeight ステップ4「ほうほう、CraftB
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い!!絶対にだ!!」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
これまでデータ・サイエンティストの選ぶプログラミング言語はRだったのだが、急激にPythonに置き換わろうとしている。 このシフトの理由はいくつかあるようだが、第一にはPython自体が汎用的で比較的学びやすい言語であるのに対し、Rが習得するにあたってやや複雑であることがあげられるだろう。 データにますます依存しつつある現代社会とデータに飢えたサイエンティストにとっては「簡単さ」こそが鍵となるのだ。 Rは実際にはプログラミング言語ではないRを覚えることに苦労する人が多い理由として考えられるのは、Rが実際にはプログラミング言語ではないからかもしれない。R専門家のジョン・クックいわく、Rとは「統計のためのインタラクティブな環境」であり、厳密にはプログラミング言語ではないのだ。彼はさらに「Rをプログラミング言語だと考るのではなく、Rがプログラミング言語を内包しているのだと考えた方が良いと分かった
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください! http://connpass.com/event/3808/ Graphs, Hashe, and Compression, Oh My! 登壇者:@matthewmccull Hashesについて 従来の CVCS (集中バージョン管理システム)のリビジョン番号は連番。 SVN はサーバーにデプロイした時点でリビジョン番号1と設定される。 Git は SHA1 をつかっている。40桁の16進数のフィンガープリントがついてる。これは理論上は重複しない大きさ。こうすることで単純で強固な DVCS (分散バージョン管理システム)がつくれる。 新しいファイルを追加すると、.git/objects/55/7db03de...(SHA1 finger print)
http://blog.fusic.co.jp/archives/1765 ↑postgresの記事ですが、mysqlでも同様に実行できました。 SELECT * FROM test_table WHERE (col,co2) IN -- 複数のカラムを指定 (SELECT subcol1,subcol2 -- 副問いの戻り値も複数のカラムを指定 FROM subtable WHERE id > 10 ) 知らなかったなんて、お恥ずかしい ※手元にあるmysqlはv.5.1.61ですが、v.4.1から使えるらしい sqlの仕様として、mysqlのdocでは分かりませんでしたが、sql99から利用可らしい http://dev.mysql.com/doc/refman/5.1/ja/comparison-operators.html ↑では、分かりませんでしたが、次のurlよれば、sql99
2013年11月12日16:19 カテゴリprogramming プライベートメソッドのテストは必要ない!! こんにちは、RPAの関口です。 最近週に一度、来年の新卒達と一緒にTDDをやりながらワイワイガヤガヤしております。そのなかで「プライベートメソッドのテストはどうすれば良いのか?」 という話題がありました。プライベートメソッドのテストについては プライベートメソッドのユニットテストは書かないもの? がよくまとまっていると思います。プライベートメソッドのテスト方法について考える中で「TDDの手順に従えばプライベートメソッドのテストがしたくなることは無い」のではないか?と思うようになりました。 プライベートメソッドはリファクタリングの結果現れる! 数値の配列を渡すと平均を計算して返してくれる機能を持ったクラス、AverageCalculatorを作りたいとします。平均計算の手順をまとめる
お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている!」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中
僕の周りだけかもしれないですが、国内のWeb受託開発案件は「PHPで作るのが暗黙のルール」ってな勢いでPHP案件ばっかりなのですが、Python大好きな僕としては、何としてでもPythonを使って仕事をしたい! なので頑張って布教活動をしているのですが、中々良い手応えが得られないのが現状です。。 という訳で、改めてPythonを使うメリットとか、安心してクライアントにPythonを進められる理由なんかをまとめてみました。 技術者がPythonを使うメリット 「今までPHPでやってきて何の問題もなかったし、これからPython始める意味なんてあんの?」 ぶっちゃけ、そんなにないですw 結果的に出来上がる物に関しては大差ないですからね。 ただし、開発効率やメンテナンス性は飛躍的に上がると僕は思います。 ライブラリがとても豊富 PHPも沢山ライブラリありますけど、Pythonだっていっぱいあるん
昨日EdTech Hackathonに行って久しぶりに色々なWeb関係の方の空気に触れて思った事。 俺はrails好きで強力だし楽しいなーと思うんだけど、 「GoogleからJSのシングルページでもSEO的にペナルティが全く無くなったらサーバーサイド要らねんじゃね?mBaaSで良くね?」 とか 「ちょっとしたサーバーサイドの処理はPHPで良くね?エンジニア多いし、安いし、技術的負債とかセキュリティ・ホールとか経営者からしたらたいして気にならないし、実際の所よくわからないし、来年どうなってるかわからんし。」 とか 「railsエンジニアとか単価高い割に何やってるのかわからないし。テストを書いてます?もっとこうガーッと派手に動く機能追加してくれねえかなあ?」 とか 「長期的なプラットフォームとかはガッツリ作ってくれて構わないけど、もっと雑でいいから短命のモバイル・アプリ量産してくれねえかな?」
書籍『Rubyソースコード完全解説』はインプレスダイレクトで御予約・御購入いただけます。 書籍紹介ページ: http://direct.ips.co.jp/directsys/go_x_TempChoice.cfm?sh_id=EE0040&spm_id=1&GM_ID=1721 HTML 版 『Rubyソースコード完全解説』の本文を HTML 形式で無償公開しています。 (2004-02-17) 全章を公開しました。 初校の修正を紙上で行ってしまったたため、現在公開しているのは初校段階の原稿です。 従って書籍では修正されているところがまだ修正されていない場合があります。 順番に修正していくつもりではいますが、いつ修正できるとは断言できません。 予め御了承願います。 なお、その逆に一部の章が出版時より新しい場合もあります。 オンラインで閲覧 tar.gz 形式でダウンロード zip 形式で
追記:翻訳に誤って訳された部分がございました。原文における「break」は「破壊する」意ではありません。お詫びして訂正いたします。また、今後はこのような誤りのないよう、最大限の注意をもってサイト運営をしてまいります。(2013.10.21 11:30) コードを学ぶベストな方法のひとつは、既存のコードを「リバース・エンジニアリング」することです。コードトーレニング企業の「Treehouse」が、コードの一部をわざと「破壊」しながら、コードを分析する方法を教えてくれました。Nick Pettit氏はTreehouseブログの中で、プラウザでの3Dプログラミングの学習事例として、Javascript「Three.js」を一行づつテストする方法を解説しています。 var light = new THREE.PointLight(0xffffff); light.position.set(-100
mixiは新人研修用のトレーニングをgithubに公開しています。 公開していることは知っていたけれど、いざみてみると… とってもわかりやすく実践的!!! 普通に参考書で勉強するよりも企業が公開しているものだから、より実践的という感じもします。 自分はこのAndroidTrainingをやっているのですが、最後に課題もあり、到達度や理解度もすごく把握できていい感じです。 READMEもかなり充実しており、一通りを学べるように工夫されています。 mixiに入社した方がこれを一通りやったと思うと、大変な印象ですが…だからこそやったときに達成感がありそうです。 開発環境の構築から書かれているので、ほとんどつまづくことはありません。 かなり詳しくわかりやすく書かれている印象を受けました。 ちょっと初めて学習するには、難しい箇所もありますが適宜ぐぐって補えばよいでしょう。 ・AndroidTrain
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く