Introduction to Gura programming language. English version is available here: http://www.slideshare.net/ypsitau/gura-introductioneRead less
Introduction to Gura programming language. English version is available here: http://www.slideshare.net/ypsitau/gura-introductioneRead less
Joel Spolsky / 青木靖 訳 2006年9月1日 金曜 旧知の友人がメールで質問をしてきた。 「Webサーバ上に構築するエンタープライズアプリケーションを作るためのテクノロジーについて、基本的な疑問がある。君の考えを聞きたい・・・」 「君だったら、.NETとJ2EEで、どちらを選ぶ?」 「Webサーバは何を使うべきだろう(Apache、IIS、その他)? その理由は?」 「どのWeb開発言語がいいだろう(ASP.NET、Ruby、Ruby on Rails、Java、Python、その他)? その理由は?」 「君の会社では何を使っているの? その理由は?」 ああ、素晴らしい質問だ。答えるのが不可能で、しかも簡単に答えられる! すまない、なぞなぞみたいな言い方はやめよう。しばらく前のことだが、私は「プログラミングにおけるロード・パーマストン問題」という文章を書いた。.NETとかJ
このブログでも何度か書いたことがあるが、ソフトウェアを書くのに高度な数学が必要なケースはマレで、ほとんどの場合は中学生程度の数学で十分である。ただし、中学生時代の数学を「公式の丸暗記」でしのいで来たような人ではなく、「難しい応用問題をエレガントに解くのが楽くてしょうがなかった」ような人が向いているというのが私の持論だ。 例として、以下の二つの数学の問題を見て欲しい。 例題1.時計の長針と短針は、12時にちょうどピッタリと重なります。次にピッタリと重なるのは何時でしょう。 例題2.サイコロを2個、順番に投げることにします。1つ目のサイコロの目の方が二つ目のサイコロの目より大きい確率を求めてください。 どちらも、中学生の数学を使って解ける問題ではある。例題1は方程式を使って解くことができるし、例題2は順列組み合わせの考えを適用すれば解くことはできる。しかし、それで満足してはいけない。 プログラ
iPhoneの一般修理店は予約なしでも来店できる? 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
今は昔、ひとりの駆け出しプログラマがいた。 その頃はCOBOLばかりで、しかも保守ばかりだった。そこで、独学で身に付けたCをやらせてもらえる仕事を奪ってきては書いた。スクラッチプロジェクトを見つける嗅覚だけは抜群だった。たいていは人手が足りず、新人でも歓迎されたからだ。 そこには優れた先達がいた。「スーパープログラマ」と呼ばれていた。 なぜ「スーパー」なんて修飾子がついたかというと、速いプログラムを早く書いたから。もちろん、「速い」とは少ないメモリ・小さいプログラムのことを指し、「早く」とは実装が早いこと。実際、彼らが書いたプログラムはサクサク動き、バグは簡単に見つけられた。 教えを請うと、先達たちは、おしなべてこういった。 最初に学ぶべきは、コンピュータサイエンス。特にアルゴリズムとデータ構造だ。実践的なコーディングテクニックよりも、まず基礎だ。これはコードを書きながらではなく、文献から
さて、というわけで、0日目〜31日目までの全32日分をすべて読み終えたこととなったが、実は本音を言うと、途中何度かあきらめそうにもなったし、全然わからねーと投げやりにもなった。楽しかったけど、同時に辛かったことも事実だ。しかし、なんとかかんとか、ここまでこぎつけることができた。本当に充実した時間だった。 だから、俺は今後もOSを作っていきます。ただ、もうこれまでのように詳細に更新、報告することはないです。多分本当に30日でOSが出来上がるのかを試してみるページの一番下のところにひっそりと公開していくだろうと思う。 というわけで、最後に感謝の言葉でこのBlogを締めくくりたいと思う。 まずは、一番最初に、この本の著者である川合秀実氏に感謝したい! ありがとう。あなたが書いたこの本で、少なからず、俺のこの1ヶ月は充実したものとなった。そして、この本をきっかけにOS作りの楽しさってのがほんの少し
PHPのすごさは何より「require」文だと思う。 require文は、いわゆる外部のphpをincludeする命令である。PHPのrequire文は、その命令が「実行した段階」からphpファイルがincludeされ、何食わぬ顔をしてあらゆる変数を引き継いだまま、include元のphpコードの続きとして実行される。 逆に言うと、require文を「実行しなければ」ソースコード中に書かれたinclude先のコードが呼び出されることはない。 これ最強だと思うんだが、他の言語ではどうなんだろう。 MVCモデルで言うコントローラーを作りたければ、 switch (分岐用変数) case 条件1: require "条件1のPHP"; break; case 条件2: require "条件2のPHP"; break; ・ ・ ・ 最低限のものなら、たった、これだけで終わり。なんなら、これだけ
This domain may be for sale!
創造的なエンジニアのための働く環境とは(1) 公開日時: 2006/01/23 18:29 著者: kenn 最近、自分のワークスタイルを大きく変えてみて、非常に強く感じることがある。 エンジニア、それも言われたことをソツなくこなすタイプではなくて、アンテナの感度が高く、自発的に新技術を磨き続けることを怠らず、自分の作ったものを広く世に出すことが楽しいと考えるエンジニアが、商業的に実りのあるモノを作り出せるようになるためには、ある特殊な条件が、きわどいぐらいのバランスで揃うことが重要なのだな、ということがわかってきた。もちろん、まだそれを理解するプロセスの真っ最中なのだけれど、考えがひとまとまりの輪郭をとってきたので、つれづれ書いてみようと思う。 ぼくは、インフォテリアというソフトウェアの会社で6年も製品企画その他、会社がリリースする「モノ」の運命にかかわる重大な意志決定に、経営
クイックソートの話で書いたとおり、相変わらず Excel - VBA と格闘する日々が続いております・・・orz 「大企業にありがちな問題。委託開発の甘い罠・・・」でも書いたとおり、今まで外注して作ったソフトウェアってほぼ 100% の確率でイケていないものが完成してます。年末に納品されたソフトウェアのできも酷いの何のって・・・ さて、いままで見てきたイケてないプログラムのダメソースに共通して言えることが3点ありまして、 DRY ( Don’t Repeat Yourself ) でない。同じもしくは似たソースのコピペが至る所に散在する。 ロジックに無駄が多すぎ。行き当たりばったりで作った感、満点。 アルゴリズム知らなさすぎ。馬鹿ループ処理で時間かかりすぎ。 のいずれか、もしくは全部が当てはまります。大抵は全部ですね。こういったソースが納品されると、センス無いなぁ〜と思っちゃうわけ。こうい
<< 2006/01/ 1 1. [教会] 元旦 2 1. 出産 2. 帰省 3. 到着 3 1. デジタル体重計のユーザインタフェース 4 1. [OOP] Classbox 2. [OOP] Classboxの実装 5 1. 帰宅 2. PCレスライフ 6 1. PC修理 7 1. 雪かき 2. [言語] プログラミング言語SRU 8 1. [教会] 断食安息日 2. あーめん 3. 筋肉痛・体調不良 9 1. 米子 10 1. [原稿] オープンソースマガジン3月号 11 1. [原稿] 日経Linux 3月号 12 1. [Ruby] Charming Ruby Compiler 2. [Ruby] The Open Nature Of Ruby 13 1. ニート娘に悩む親 2. Python Status Update 3. 泥縄 14 1. 宣教師のお手伝い 2. Simpl
WWW::Mechanize の 1.17_01 がリリースされていたので、見てみたら、1.16 で (というか 1.06 以降で) リダイレクトされた後に uri() を呼ぶと、リダイレクトされる元の URL が返るというバグに対して、送った patch が取り込まれてない。 完全無視されている。 てか、基本的にはテストだけ直された模様。 どういうバグなのか、簡単に言えば、 http://www.example.com/ → http://a.example.com/ → http://b.example.com/ → http://c.example.com/ とたらいまわしにリダイレクトされるサイトがあったとして、上記の場合 use strict; use WWW::Mechanize; my $mech = WWW::Mechanize->new; $mech->get('http
三十歳にしてプログラマに転向 Posted by Gosuke Miyashita Mon, 23 Jan 2006 08:17:54 GMT 一応会社でも部長から部のメンバーへ発表はあったので、ここでも書いちゃいます。転職します。2月から paperboy&co. の中の人になります。しかもタイトル通り、三十歳にして初めて本職プログラマになります。 もちろん、開発だけをするつもりは全然なくて、サービスの企画だとか、ディレクションだとか、デザイン(ビジュアルではない)だとか、総合的に積極的に関わっていきたいな、とは思ってますが、あくまでも中心は技術(開発以外も含む)に置きたいと思っています。 97年に社会人になってから04年10月までは、メール、LDAP、ウェブ、プロキシ、ポータル、アイデンティマネジメント、などといったサーバ製品の構築を担当していました。(特にメールや LDAP がメイン
JavaScript is disabled on your browser. Please enable JavaScript to use correctly mesosadmin frontend Please login Login Password Forgot your personal password ? We can remind you
どっちが良いとか悪いとかは関係なく、世の中のオープン技術で開発をしている会社は、 ・Java + Oracleを主流とする会社 ・Perl + MySQL、PHP + MySQLを主流とする会社 と、完全に二層に分かれてるなと思っている。 はてブ経由で見つけて、mixi内のリンクしちゃうけど、 業務経歴書にPerl案件を書くと馬鹿にされる件 就職活動の面接でPerlやってますとアピールすると、Java圏の面接官にバカにされるという話があった。 ありきたりだけど、Perlを良しとする会社は、エンジニアリング指向が強くて、自分で解決したい方向性が強い。割と柔らかくてもOK。ライブラリに不備があったら、直して使ってしまおうというタイプ(というか、きっとそれが求められる) Javaをメインとする会社は、きっちりしていたいと思う指向が強く、それこそPerlのライブラリのようなのを適当で、うさんくさい
http://martinfowler.com/bliki/ImplicitInterfaceImplementation.html JavaもC#も純粋なインタフェース型というものを用意している。 純粋なインタフェースはinterface Mailableのように宣言し、 Javaの場合だとclass Customer implements Mailableのようにして実装する。 ひとつのクラスは複数のインタフェースを実装することができる。 このモデルが考慮していないのは、 クラスには必ず暗黙的なインタフェース(implicit interface)があるという点である。 Customerの暗黙的なインタフェースは、Customerで宣言されたすべてのpublicなメンバである(この暗黙的なインタフェースは、今まで私が見てきたどのOO言語にも存在する)。 JavaでもC#でも、暗黙的なイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く