You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はへん 破片プログラマー 大きなシステムの改修、 巨大に積み上がったプログラムの上での実装、 難度の高い仕事、 ただし破片 巨大な破片 画面を0から 二年、三年、五年と経験を積み、 開発スキルを身に付けたディベロッパー、 だがしかし、 0から画面を作ってみると... ... あれ!? できない。 画面を0から作ったことがほとんどない。 あったとしても、隣の画面の真似ごとをしてただけ。 考えて0から作ったことがない レールのないところ歩いたことがない。 クラスやメソッド クラスを作る。 どうやって?どういう単位で? 決められた中でしか作ったことがない。 その決めがないと何もアイディアが浮かばない。 「どこに何を実装するか?」って、 白いキャンパスの上で考えたことがあるかい? ... メソッドを作る。 どうやって?どういう名前で? どういう引数と戻り値で? メソッドの修正はたくさんしてきたが、
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回(毎週火曜日に掲載、これまでの連載一覧)。「WEB+DB PRESS Vol.80」(2014年4月24日発売)に執筆した「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部) 文:西尾 泰和 イラスト:歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月24日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、SQLにおいて「暗黙の型変換」を使うべきでない理由として、具体的な「ワナ」をいくつか紹介します。 数値項目に対するSQLインジェクション対策のまとめにて説明したように、RDBの数値型の列に対してSQLインジェクション対策をする方法として、以下の三種類が知られています。 バインド機構を用いる パラメータの数値としての妥当性確認を行う パラメータを文字列リテラルとしてエスケープする このうち、方法3を使うべきでない説明の補足です。具体的には、方法3には、「暗黙の型変換」が発生しますが、それが思わ
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
i'm currently based in boston 🇺🇸 (and sometimes tokyo 🇯🇵) i currently work at the dana-farber cancer institute, department of pediatric oncology in the gillani lab. i'm also fortunate to be affiliated with the van allen and janeway labs at dana-farber, and the broad institute, cancer program. we aim to understand why and how rare, aggressive pediatric solid tumors (all non-blood cancers) arise
SQLはデータベースからデータを抽出したりするための言語です。 この文書は、ErogameScapeのデータベースからSELECTを使って自由自在にデータを取得できるようになることを目標にします。 エロゲーをやりはじめる大学生くらいのときに、大学の講義でデータベースを学んで、退屈だなーと思った時に、ErogameScapeでSQLを学ぶことで、少しでもSQLに興味を持って、自身でデータを加工することを学習して頂けると幸いです。 ※私の大学のリレーショナルデータベースの授業では、自分の身の回りの何かをER図に落とし込んで、DBを設計し、PostgreSQLに実装し、実際にデータを入力してSELECTしてみるところまでをやりました。 ER図という概念を学んだとき「ああ、これは面白い」と思いました。 先生はこう言ったのです。 「ER図に落とし込むと、思いもよらなかったことが分かる。」と。 当時、
概要 これまで「Hiveからデータ取得・簡単な加工→Pythonで加工・分析」 という流れで作業していたのですが、 Hive→SQLite→Pythonという流れにしたところ進捗が改善されたので、 SQLiteの簡単な使い方とPythonによるSQLユーザ定義関数の組込方法 についてメモを残しておきます。 特にユーザ定義関数の組込を自由に出来ると、 分析する際、相当楽になるということに気付きました。 SQLite挟むことで何がどう改善されたの? Hiveはデカいデータをゴリゴリ取ってくる分には SQLちょっと書くだけで済むので大変便利ですが、 初動遅いためちょこちょこ小さいデータを何度も取ろうとするとストレス溜まります。 そのため、これまではある程度のデータをまとめてHiveで落としてきて Pythonで加工してから分析するという流れを取っていました。 ただ加工するために似たようなコード何
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い!!絶対にだ!!」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
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)
はじめに 私たちが通常、C言語やPerl、Javaなどの手続き型言語(またそれに基礎を持つ言語)を使ってプログラミングを行う場合、最も多用する基本的な制御構造が分岐とループです。この2つを使わずにプログラミングしろ、と言われたら、それはかなりきつい制約になるでしょう。腕試しや暇つぶしに試すにはおもしろいかもしれませんが、およそ実務的なコーディングは不可能になるに違いありません。 話は、SQLとデータベースの場合でも同じです。SQLにおいても、やはり分岐とループは非常に重要な役割を果たす機能であり、SQLプログラミングの際にこの2つの機能を欠かすことはできません。しかしながら、手続き型言語を使いこなすプログラマの多くが、なぜかSQLを使う段になると思い通りの制御構造を記述できないことに苛立ちを感じ、結果、非効率的なSQL文が多く生み出されています。これはなぜでしょう? SQLで分岐とループを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く