どのプログラミング言語を最初に覚えるべきかとたまに聞かれる。聞き手はさまざまだ。アカデミアの人や営業をやっている同僚、トレーダー時代の元同僚など。まあ、こんなエセプログラマーに聞いている時点で既に間違っているのだが、今まではテキトーなことを言ってきた。 やっぱプログラムを始めるならC言語で基礎からじゃないっすかねー JavaScriptだったらブラウザで走りますし、お手軽ですよ！ Pythonいいっすよー読みやすいし 日本人ならMatzに敬意を表してRubyじゃないっすか 数学者なら意外とHaskellがとっつきやすいかも... 我ながら無責任なものである。RubyとHaskellにいたっては書いたことすらない。なんでこんないい加減な受け答えをしてきたかといえば、どの言語でプログラミングを覚えるかは、さほど重要ではないと考えているからだ。例えば世界的にウンコ言語とされているPHP1でも優秀
► 2022 (2) ► 10月 (1) ► 2月 (1) ► 2021 (51) ► 11月 (2) ► 10月 (2) ► 9月 (4) ► 8月 (4) ► 7月 (4) ► 6月 (4) ► 5月 (3) ► 4月 (10) ► 3月 (7) ► 2月 (4) ► 1月 (7) ► 2020 (155) ► 12月 (7) ► 11月 (10) ► 10月 (8) ► 9月 (8) ► 8月 (11) ► 7月 (21) ► 6月 (19) ► 5月 (14) ► 4月 (20) ► 3月 (13) ► 2月 (10) ► 1月 (14) ► 2019 (293) ► 12月 (11) ► 11月 (12) ► 10月 (24) ► 9月 (29) ► 8月 (27) ► 7月 (36) ► 6月 (40) ► 5月 (24) ► 4月 (35) ► 3月 (42) ► 2月 (6
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
東京ラーメンショー2011 いきてーーー！みなさんこんにちは、nakamura です。 今日はプログラマだったりサーバ管理者だったり（もしくはその両方だったり）する方にお勧めしたいサイトとツールをいくつかご紹介します。細かい脆弱性のチェック等どうしても手間が掛かるものが多いですが、今回ご紹介するツールをうまく使うとその辺りだいぶ効率よくできると思いますよ！ WEB アプリケーション関連 XSS Me XSS Me :: Add-ons for Firefox XSS のテストをある程度自動化してくれる Firefox のアドオンです。残念ながら Firefox3.0.* 系の頃に開発が止まってしまっているようですが、僕の環境では install.rdf の書き換えで問題なく動作しています。（Windows7 64bit + Firefox7.0.1） SQL Inject Me SQL I
プログラマはワンパターンである 先月(7末)くらいから、勉強会、イベントに参加して社外のプログラマと接することが多くなった。 プログラマとは、一生、技術の追求をしてそうな人たち。 具体的には、3つ以上の言語を取得してる人たち、とでも言えばいいのだろうか。 有名コミッターな人、年間300冊以上の技術関連の本を読む人もいるのだけど、 だいたい月2回以上勉強会に出ているような人たちで、私からしてみれば同じだ。 そして、プログラマと友達になることで、気づいたことがいろいろある。 こういってしまっては何なのだが、プログラマたちは非常にワンパターンなのだ。 コーダーは多種多様である。すごくおもしろい人、変わった人がいたり、 最高にいい人から、最低に悪い人までいろいろいるが、プログラマは ほとんどパターンがない。もちろんこれは絶対的にコーダーの数のほうが多いわけで、 数が多いから多種多様であるだけなのか
Other Languages: 한국어 Русский 简体中文 About Scala school started as a series of lectures at Twitter to prepare experienced engineers to be productive Scala programmers. Scala is a relatively new language, but draws on many familiar concepts. Thus, these lectures assumed the audience knew the concepts and showed how to use them in Scala. We found this an effective way of getting new engineers up to spe
JavaJavaの匿名クラスはすごくかわしいかわいい技術でいろいろキモイことができます。匿名クラスは基本的に「サブクラス生成のための特殊記法」であって、クロージャではありません。匿名クラスとクロージャを対比して云々するのはそもそも誤りです。なんならクロージャでサブクラス作ってみなよってことです。匿名クラスによって、Javaではなにかのサブクラスを任意の場所で即座に作り出すことが出来るんです。なにかのクラスのメソッドを三つほど書き換えた新しいクラスをさっと作れるのは、なかなか面白い機能ですよ。 その匿名クラスを利用したカッコイイ（でも使うのは躊躇されている）記法として、次のようなのがあります。（追記：この用法はヨシオリさんところで見たのが最初です） List list = new ArrayList() {{add("a"); add("b"); add("c");}}; Javaには「初期
最近のWebシステムは、クライアント依存しづらくしなきゃだめよねー、ということで、サーバサイドにはJava、クライアントはJSON+JavaScriptでレンダリングという構成でシステム構築を考えております。そんな中で気づいた事をメモっとこうかなぁ、と。 なんでそんな構成にするの？ PCのWebブラウザだけでなくスマフォのブラウザやネィティブなアプリに対応しやすくするためです。サーバサイド処理を変えることなくクライアント側の処理で対応させちゃおうということです。サーバサイドの処理はJavaでなくてもPHPやRubyでもなんでも良いわけです。クライアント側と会話さえできれば。 サクサク感がたまらない 今まではsubmitして画面表示しなおすという方式が当たり前だったのですが、この方式に慣れてしまうと、画面遷移がモサく感じます。何か、ボタンを押すたびに画面が切り替わってスクロールバーが一番上に
_ 35歳プログラマ定年説はもう時代遅れ。職業プログラマは32歳定年説を推します 今冬のチーム体制を議論する季節になってきました。とうとう私はプログラマとして招へいされることが無くなりました。 ジョジョの奇妙な冒険第二部風に現状を説明すると以下です。 tamoot は・・・二度と Ruby on Rails を使った開発のお仕事には戻れなかった・・・ サポートのようなお仕事と、バグ調査・パッチ作成のお仕事との中間の生命体となり永遠に会社をさまようのだ そして開発のお仕事をしたいと思っても招へいされないので・・・・ -- そのうち tamoot は考えるのをやめた 私をプログラム開発業務へまわすデメリット 客観的に見て以下です。弊社ならやはり定年として扱われても仕方ありません。 時間単価が高い 偉い人はプログラミングごとき下流の作業は単価の安いやつにやらせるという方針です。 明らかに間違って
このまえ登り坂の途中でロードバイクのタイヤが破裂しました。ながたです。 今回はバッチ処理について書いてみようと思います。 バッチ処理？ Webサービスの処理開始条件は、大まかに次の2つに分けることができます。 ユーザーのアクションに起因するもの ユーザーのアクションに起因しないもの このうち後者の処理をバッチ処理が担当することになります。 バッチ処理の担当分はさらに、 特定の条件（時間やサービスの状態）で実行するもの 手動で実行するもの の2つに分けられます。 今回はこの「手動で実行するもの」について書きたいと思います。 バッチを手動実行するのはどんなとき？ バッチ処理を手動で実行するのは、十中八九イレギュラーな状況が発生したときです。 ルーチンワークや実行の条件が決まっているものは何らかの方法で自動化できるはずです。 そしてイレギュラーな状況のほとんどは不具合が発生したとき。 つまり 重
好きでやっているソフトウェア開発の仕事だけど、周囲を見渡すと実はこんな仕事は好きではないと言い切る人が多くて驚いたことがある。与えられた仕事だけをやっておけば万事OK、チーム全体のレベル向上やプロセス改善、新しい創意工夫なんて自分には関係ないことだし、そもそも仕事に関係しない余計なことに巻き込まないで欲しいと、面と向かって言われたこともある。会社で働く人の目的は実に様々なのだ。 このような開発者が増えてくると、チーム全体としての品質・生産性向上なんて見込めなくなるし、投資対効果を求める会社としては「スキルなんか要らないから人月単価の安い人が欲しい」と外部の会社に求めるようになってくる。一部のやる気とスキルのある人たちが方針と手順を決めて、残りの人はそのルールに従うのみという「ソフトウェア工場」が出来上がるわけだ。 ソフトウェアエンジニアとそれを取り巻く不幸な環境は、長い年月に渡って形成され
http://slashdot.jp/askslashdot/article.pl?sid=08/03/16/041249 表現力とは、例えば図面を書く能力であったり、コードを書く能力であるのですが、それだけではなく人に物を伝える能力や統率力も含まれます。 図面を書いたり、コードを書く直接的な表現力は、歳を重ねるごとに絶対的（手が遅くなるとか、直感的な思いつきが減って考える時間が増えるとか）・相対的（新しい手法をもった若手が増えることで、結果的に同じ事を表現するのに時間が掛かるようになったり、そもそも新しい環境向けたハード・ソフトを設計できなくなる）に失われていきます。 http://slashdot.jp/askslashdot/comments.pl?sid=393811&cid=1313966 これはないと思う。やっぱりずっとコードかいてる人はどんどん効率のよいコード書くようになって
無知なリーダーがもたらす災厄 - Basic 無知というのは恐ろしい。ほんの少しばかりの好奇心を持って書籍を読んだり、ブログを読んだりして勉強していれば当然知っているはずのアタリマエの知識を知らなかったりする。しかもこの人はチームを取りまとめるリーダーという存在なのだ。効率の悪い作業方法をメンバに命じて、結果的に組織へ損失をもたらしているのに、その結果に気がついていないのだ。 無知というのは恐ろしいというのはその通りなんだけど、これはリーダー一人を責めても仕方ない面もあるかなとは思う。 私自身、評判のイマイチなSIerに長く在籍していて技術力や知識の無い人と一緒に仕事したり山ほど見てきたりして麻痺しているのかもしれないけど、上記のようなケースでは配下のメンバーから突き上げが必要なんじゃ無いのかなぁとも思う。 例えば上の例だとコミットメールを引き合いに出しているけど、配下メンバーが誰もSub
実際に書かれているコードの品質を確認できない、しないリーダであれば、単にスケジュール管理だけになりがちです。そのため、品質優先ではなく納期優先の管理となったりします。遅れが発生した場合に、何が原因かということに対して現状把握を行い対策を打つことをせずに、担当者に「納期に間に合うように対策を考えて再スケジュールしなさい」という指示だけだったりします。 しかし、遅れの原因は、仕事の難易度が高かったり、あるいは、担当者のスキルレベルが低かったりすることがあります。その場合、コードを書いている担当者は、遅れを挽回する対策を考えることは無理かもしれません。しかし、リーダは、コードを見ることもないので、再スケジュールしなさいとか、早く不具合を修正しなさいとしか言えなかったりします。 リーダがコードを読んで品質を確認できることは、仕事の難易度と技術者のスキルレベルを把握して、適切な仕事の割り当てを行い、
開発組織としてメンバーのスキル向上を行うためには、経験豊富なエンジニアの知識をレビューという形式で伝えていくことが重要です。そして、たとえ初心者であっても、繰り返しきちんとしたレビューを受け続けることにより、成長させていく必要があります。コードレビューは、ソフトウェアの品質を作り込む場でもあるのですが、同時にエンジニアを教育する場でもあったりします。 しかし、開発組織がコードレビューに関して否定的だと、開発プロセスでレビューすることが規定されているというだけの理由で、初心者レベルのエンジニアだけでレビューを行わせたりします。ここで「初心者レベル」というのは、ソフトウェア開発経験年数が少ないという意味ではなく、きちんとしたコードを書くということに関して初心者レベルという意味です。 コードの品質に興味がない人がリーダとして開発チームをリーディングしている場合には、開発が遅れてくると大量に初心者
ソフトウェア開発は、自分で考えて手を動かしてプログラミングして動くものを作ることを繰り返す訳ですが、そもそもソフトウェア開発という「物作り」を好きではないサラリーマンエンジニアが日本には多いのではないかと思います。 その理由は単純で、新卒新人でも中途入社であっても、自分で分析・設計から実装・デバッグまでするのが好きな人を採用していないからだと思います。たとえば、メーカーでソフトウェア開発部門に配属されるような新卒新人でも、大学ではほとんどプログラミングしたことがない人をメーカーは採用します。中途採用であっても、採用面接でプログラミングを伴う技術的な質問をほとんどしません。 その結果、企業の中には、本当にソフトウェア開発が好きなソフトウェアエンジニアと仕事だからというサラリーマンエンジニアがいることになります。そして、サラリーマンエンジニアは、そもそも好きではないので、業務がこなせるようにな
最近またプログラマ35歳定年説をよく目にするようになりました。 「日本の典型的なSIerの世界では」という前提であれば、35歳定年説はあながち間違ってないのかもしれません。でもその前提となっているSIerの体制自体には大きな疑問を感じます。いったい何が問題で、どうすれば生涯プログラマとして生きていけるのでしょう？ 日本のSIerの不自然なカースト制度 プログラマ35歳定年説はPM・SE・PGといった日本のSIerの不自然な職種分離が最大の原因です。 PM/SE/PGは別のスキルが必要なのに、年齢とともにジョブチェンジしていかなくてはならないプレッシャーがあります。大手SIerではろくにプログラマを経ることなくいきなりSEとしてデビューしたりもします。 こんな変な仕組みが出来た原因はソフトウェア開発の本質があまりわかってないときに製造業モデルを無理やり当てはめたからではないでしょうか。 この
さて、アルゴリズムの勉強のしかたと、ラムダ計算の勉強のしかたの目星をつけました。 アルゴリズムの勉強のしかた - きしだのはてな ラムダ計算の勉強のしかた、プログラム意味論 - きしだのはてな これでここで書いたプログラムの理論の基礎は勉強できたことになるんじゃないかと思います。 プログラムの理論とはなにか - きしだのはてな ところで、プログラムの勉強地図としてこういう図を書きました。 で、ハードウェアまわりについても、プロセッサを支える技術やネットワークはなぜつながるのかでひととおり勉強したとしましょう。 じゃあ次は、アジャイルか？テストか？UIデザインか？となるわけですが、やはりプログラマなら、プログラムの作り方や使いやすさの前に、作るプログラムの機能や性能で勝負したいじゃないですか。 いい感じに関数が分割できるよとか、読みやすい名前がつけれるよとか、効率よく仕事して定時に帰れるよと
隣のチームの仕事ぶりを知ると、自チームで当たり前に出来ていることが全然出来ていなかったり、或いはその逆のケースも有ったりして興味深い。ペアプログラミングなんて言う言葉があるけれど、チームリーダは隣のリーダと一緒に働いて互いの働き方から学ぶべきではないかと思ったりする。リーダーがペアでマネジメントを行えば、もう少しマトモになるチームも多いのではないだろうか。 以前に見たある開発チームでは、ソースコードのコミットの度にその旨を通知するメールをメンバー全員に手作業で送っていた。もちろん、手作業だから忘れることもあるし、必要な情報が欠落していたり、誤記が有ったりする。そんな面倒で、しかも不確実な作業をなぜ繰り返し行なっているのか担当者に聞いてみたら「それが決まりだから」という返事しか返ってこなかった。 ルールであることは分かっている。知りたいのは「何のためにそのようなルールがあり、メール送ることが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く