ちっちゃいCoffeeScriptの本
東京住まいの外国人プログラマーが日本人のプログラミング世界について記事を書いて (Jawaad Mahmood 氏のブログ記事)、その記事が Hacker News で取り上げられて、話題になった。 "My hypothesis is that a lot of Japanese companies produce little new because they have people solving solved problems over and over again." 以下、拙訳。(*) がついているところは訳していて意味がくみ取れなかった部分なのでコメント頂ければ幸い。誰か Hacker News へのコメントも要約してくれると助かる。 昨日、コーヒーを飲みながらアール氏とアキバに関する話題やらボードゲームやビジネスについて話していた。まじめな話題としてはプログラミングについて、
www.scratch-ja.org このページは、子どもプログラミングサークル”スクラッチ”、OtOMO等の名前で埼玉県川口市のメディアセブンや三軒茶屋の生活工房・市民活動支援センターで活動していたグループによって管理されています。 現在は引き続き以下のページで情報提供しています。 OtOMO https://otomo.scratch-ja.org/ on X https://x.com/Scratchja Scratch Day in Tokyo 最新情報 https://day.scratch-ja.org/ 2019年以前 https://days.scratch-ja.org/ 連絡先 scratch.ja(at)gmail.com www.scratch-ja.org 2025
再帰的に定義される、3個の引数 x, y, z をとる次のような関数である。 特に変わる所は無いがLisp版[1]も参照のこと。定義からわかるように処理を次々にたらい回しにしていくことから、たらいまわし関数[2]、たらい関数 (Tarai function) とも呼ばれる(後述のマッカーシー版との混同を避けるためこの名で呼ばれることのほうが多いが、こちらの定義のほうがオリジナルである。マッカーシー版を特にTak関数として区別する場合もある)。電電公社研究員(当時)の竹内郁雄が、1974年の夏前の頃、後述するような特性のある関数をあれこれ考えていた、ある日の午前に思いついたものである[3]。竹内関数と命名したのは野崎昭弘である[4]。 特性として、よくベンチマークに使われる関数であるフィボナッチ数を何の工夫もなく計算するいわゆるダム(dumb)フィボナッチと比較して、大きな数の計算が必要ない
なぜ、うっかりTwitterやmixiに自分の秘密を書いてしまうのか 「Twitterはバカ発見器と言われている――なぜ人はTwitterやmixiなどで秘密を話すのか?」 8月10日、情報セキュリティ基礎の講義を担当する、サイバー大学IT総合学部准教授の園田道夫氏は、こう問い掛けた。 「例えば、未成年者が飲酒・喫煙を暴露するケースなどがある。情報はすぐに全世界に公開されるにもかかわらず、なぜ自分にとって都合の悪いことを書くのか」 「なぜ、ソーシャルメディアを見ているのが身内・友達だけだと思ってしまうのか」 園田氏の問い掛けに対して、参加者はグループになってさまざまな意見を出した。 「ツイートはフォロワーからしか見られていないという認識があること、そして気軽につぶやけるということが原因ではないか」 「友人などの紹介で始めることが多いので、プライベートなエリアだと勘違いしているのではないか」
(function(){...})()は、 (function($){ $.hoge = function() { }; })(jQuery) みたいに使われていたりするコード。GreasemonkeyとかjQueryのプラグインとか、あれこれ見かけることがあると思います。 この話題はいくつかWebでも取り上げられていますが何がどうなってんのかちょっと難しいですね。しかし、誰でも理解できるレベルではあります。というのも、こういう種の難しさは体系的な知識が備わっているか否かということなのです。 でも、この知識を体系化する作業って結構しんどくて、難しくて、まーハゲるほど悩むこともあるかもしれない。それはきっと、とても毛根に悪いかもしれない。スカルプDも真っ青の状況になるかもしれない。それは、悲しいことなのだと思う・・・っ! 毛根にはこれからもがんばってほしい!いつだって頭を温かいまなざしで見守
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
何百回、何千回と見慣れた画面、見間違えるはずもない。すぐにそれが自分の作品だと直感したものの、どうしても信じられなかった。いや、だって、一介のアマチュアプログラマが作ったWebアプリが、ミッションの中でも一番クリティカルな大気圏再突入前のミッションコントロールセンターの画面に映っている*1。これで信じろという方がおかしい。見慣れたアイコン、昼夜境界線、ISS/シャトルの軌道を示す赤いグラウンドトラック、うっすら見える左上の設定アイコン、全部同じだ。でも... そして、すぐに一つの事実に気づいた。いつもは、軌道離脱噴射の終了を見届けた後シャトルのトラッキングを止める。公開されているデータではここから先の軌道を追うことはできない。放っておけば徐々にずれが大きくなる。でも、もし、あそこに映っているのが本当に自分の作品なら、ここで設定を変えるとあの画面からシャトルが消える、そんなことをしていいのか
Products Discover Heroku’s AI PaaS (Platform as a Service), designed for effortless app deployment and scaling. Explore our cloud application platform features, reliable managed data services, and a robust ecosystem to power your modern applications. Elevate Your Salesforce Practice with Heroku Join us for a webinar! Learn how to grow your business with Heroku - explore the new offerings and benef
アプリ制作において新しいデザインを生むのはやっぱプログラマのほうですね。 デザイナはどうしても概念を「かたち」に置き換えて理解するクセがあります。たとえばアプリの画面フローなんかを作るときにすでに頭の中では画面と画面が、なにがしかの概念を表す構造図になって関係しあったりしてます。構造図になっていること自体は悪くないんですが、何か新しいものを作ろうとする時、構造にあてはめて考えようとすると結構陳腐というか、アイデア的に弱い感じになりやすい気がしています。うまくいえませんが「デキル前からすでにかたにはまっている」というかんじです。デキてからの仕事としてはデザイナに負う部分は大きいのですけどもね。 基本プログラマちゃんの頭の中では構造なんかは眼中になく、それこそ設定した目的を、なかば場当たり的に処理する過程で必要な画面が、適当にフローして、結果を吐く。それが結果的になにか既存の構造に似てるね、と
僕の知っている範囲だと、優秀なプログラマはフリーランスか小規模な法人のオーナー社長であることが多い。人を雇っている場合でも、ほんの数人である。もちろん僕もその一人。そりゃまあGoogleやMicrosoftの本社には凄いプログラマもいるだろうけど、日本人だと本当に一匹狼系の人が多い。 僕もフルタイムの従業員を雇って1年以上経ち、人を雇うと何が起きるのかについてけっこう分かってきた。なので、なぜこのようになるのかについて考えてみた。 なんと金銭的な面「だけ」でも、合理的な理由をつけることができる。僕を含めた何人かを平均したモデルで例を出してみよう。すごく単純化しているけれど。 いま一人の優秀なプログラマがいて、平均的な会社でサラリーマンとして働いても年俸1000万取れる実力があるとしよう。この人が独立した場合、「好きなプロジェクトを選べるのでやる気が出る」「独立していることについてのリスクプ
なんか、極めると「ほむほむ」だけで会話できるみたいですね? 俺はまだそこまでの域には至ってないんですが、「ほむほむ」だけでプログラミングできたらステキですよね? そこで、ちょっと草植えときますね型言語 Grassを元にして以前作ったプログラミング言語「天使ちゃんマジ天使」とか 「ブブゼラ」をベースに、 またまたネタ言語を作りました。 Grassの文法と異なる点は以下のとおり。 wがほむ スペース・タブにはさまれた"ほむ"がW vは改行 wを出力するプログラム: ほむ ほむほむ ほむほむほむほむ xを出力するプログラム: ほむ ほむほむほむ ほむほむほむほむ ほむほむほむ ほむ "Hello, world!"を出力するプログラム ほむ ほむ ほむ ほむほむほむほむ ほむ ほむほむほむほむほむほむ ほむほむほむほむほむ ほむ ほむほむほむほむほむ ほむほむほむほむ ほむほむほむほむ ほむほむほ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く