序文 しばらく前から、プログラマーを対象とした圏論に関する本を書こうと考えていた。計算機科学者ではなくプログラマー、科学者ではなくエンジニア向けだということに注目してほしい。正気の沙汰ではないし、本当に恐ろしい。科学と工学の間に大きなギャップがあるのは否定できないと思う。自分自身がその分断の両側で仕事をしてきたからだ。それでも、物事を説明したいという強い衝動をいつも感じていた。簡潔な説明の達人だったリチャード・ファインマン1を心から尊敬している。自分がファインマンではないことは分かっているが、最善を尽くしたい。まずは、この序文――読者に圏論を学ぶ気を起こさせることを想定したもの――を公開することから始めようと思う。それによって議論を開始しフィードバックを募れることを願っている2。 ここからの数段落をかけて、この本はあなたのために書かれたものであり、数学のうちでも特に抽象的な分野を学ぶために
はじめに 学校で習わないが(習う学校もある)、現実に必要になるプログラミング技術に、低レイヤプログラミングなどと呼ばれるものがある 厳密な定義は聞いたことがないし、おそらく存在しないとは思うが、大体のみんなの共通認識として、 「高級プログラミング言語を使わないプログラムを書き、OSで抽象化されないデバイスの機能を使う」といったような認識があると思う。 筆者の経験から言わせてもらうならば、低レイヤプログラミングに関する知識は、プログラミングにおいてあらゆる場面で、常に、少しずつ役立てられる知識だと言えると思う。 普段はRubyやPHPなどを書いてる人であったとしても、メモリが足りなくなった場合や、デバッガを使っている場合、性能が足りなくなった場合など、 厳しい環境におかれた時に低レイヤプログラミングに関する知識が必ず役に立つ場面が来ると信じている。 また、役に立つかどうかは置いておいても、「
------- GND -- |01 31| -- +5VCPU A11 -> |02 32| <- M2CPU A10 -> |03 33| <-CPU A12CPU A9 -> |04 34| <-CPU A13CPU A8 -> |05 35| <-CPU A14CPU A7 -> |06 36| <>CPU D7CPU A6 -> |07 37| <>CPU D6CPU A5 -> |08 38| <>CPU D5CPU A4 -> |09 39| <>CPU D4CPU A3 -> |10 40| <>CPU D3CPU A2 -> |11 41| <>CPU D2CPU A1 -> |12 42| <>CPU D1CPU A0 -> |13 43| <>CPU D0CPU R/W -> |14 44| <- /ROMSEL (/A

自分にとっての要点メモ。 EffectiveC++の著者のScott MeyersによるC++11/14の定番本(らしい) ※知らずに買ったら英語だったので、なんとか通読しましたが理解は随所怪しいと思われます。誤りは是非ご指摘ください。 2015/11/02追記: 日本語版が出ています。本稿は日本語訳が出る前に書いたのなので目次の訳は一致しません。ご注意ください。 https://www.oreilly.co.jp/books/9784873117362/ 第1章: 型推論 autoやdecltypeによる型推論はコードの冗長性を減らす強力な機構だが、型推論の動きをしっかり理解していないとmodernC++での効率的なプログラミングはほぼ不可能。 1: テンプレート型推論を理解しろ 関数テンプレートtemplate<typename T> void f(ParamType param)

すべてのMicrosoft 製品 GlobalMicrosoft 365 Teams CopilotWindows Surface Xbox セール 法人向け サポート ソフトウェアWindows アプリAI OneDriveOutlook Skype から Teams への移行OneNoteMicrosoft TeamsPC とデバイス Xbox を購入する アクセサリ エンタメ Xbox Game Pass Ultimate Xbox とゲームPCゲーム 法人向けMicrosoft CloudMicrosoftSecurity Azure Dynamics 365 一般法人向けMicrosoft 365Microsoft IndustryMicrosoft Power PlatformWindows 365 開発者 &ITMicrosoft 開発
John Hughes, Institutionen för Datavetenskap, Chalmers Tekniska Högskola, 41296 Göteborg, SWEDEN. rjmh@cs.chalmers.se この日本語訳は原著者の承諾を得て山下がここに公開するものです。 この訳文についての、御指摘などは山下伸夫(nobsun .at. sampou.org)までおねがい いたします。 翻訳最終更新日 : 2011-09-17 原文 "Why FunctionalProgramming Matters" 日本語訳PostScript この論文は1984年以来何年ものあいだChalmers大学のメモとして回覧された。 1989年と1990年に幾分か改訂をしたのが[Hug89]と [Hug90]である。この版はもとのChalmer大学のメモ のnroff原稿をもとに
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 結論:Javascriptの乱用をやめるのが一番。 はじめに書いておきますがしょうもない話です。 結論、開発者としてはどのような方向性でやるべきか、を書いています。 JS多い時代でのフレームワークの根本的な問題云々のことは書いてません。 さて、現状、モバイルにおいて、Javascriptでまともに動くものを作ることは難しいです。Twitterから引き抜いた超優秀なWebエンジニアを多数抱えるMediumですら、未だにモバイルで多数のバグを抱えています。 超優秀なエンジニアを世界一抱えているであろうGoogleのGmailですら、モバ


はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル(=クラス)やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby onRailsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません! payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

ThreadよりもTask for (int i= 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a[i]) ); } ×悪い例 ○良い(まだマシ※な)例 データの数だけ スレッド作成 Threadでなく Task利用 ※ この場合、ParallelクラスやParallel.Enumerableクラスが使いやすい ThreadよりもTask for (int i= 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a
この文章について OOP(オブジェクト指向プログラミング、オブジェクト指向パラダイム)について プログラミング勉強中の大学生さんに説明する機会が何度かあったので、 自分の中で整理するために書きました。 中には適切でない説明もあります。ばっさり省いているところもあります。 詳細より イメージを掴んでもらうことを優先しているためです。 「それにしてもあんまりだなー」という表現がありましたらご連絡いただけると嬉しいです。 大学生さん 大学生さんたちはいろんな背景を持っています。 プログラミングを始めたばかりの人 独学で Objective-C やJavaScript を書いた経験がある人 Web やコンピュータの仕組みについてもこれから勉強する予定の人 使用言語 大学生さんたちはプログラミングの第一歩としてJavaScript とPHP を使っています。ここでは説明にPHP のコードを使

追記: 続編を書きました。マッチョとの戦い 最近、プログラマの生産性が話題です。 いろんな意見があるものの、個人的には 10〜100倍の生産性の違いはあると思います。 いや、それは違う、生産性の高いエンジニアは生産性の低いエンジニアに作れないものが作れるのだからそういう話ではない、という意見もあります。 しかし、実際には生産性の低いエンジニアができもしないことをしようとして結局できないで終わるということがあったりしつつも、何らかの貢献をするというのが普通だと思いますので*1、最終的には 10〜100倍の違いといった形に落とし込めると思います。 で、この生産性の違いはどこから来るのか。 個人的には才能だと思っています。 ぼく自身は、自分のことを中間レベルのエンジニアだと認識しています。 平均の 3〜10 倍できて、トップより 3〜10 倍できないくらい。 でも、自分が平均から抜け出るために何

VB6(Visual Studio6.0)がWindows7や8で使えずいずれサポート打ち切り、最悪はそのEXEも次期OSでは動かなくなる恐れから止むをえずVB2008へ変換を試みていますが、余りにVB2008は利用者泣かせよくもこのような製品を世に出したなと言わざるを得ません。VB6で便利に使えていた機能をことごとく排除、オブジェクト指向と言う単に技術者の傲慢、自己顕示欲を示すだけの製品になっている。オブジェクト指向になってどこがどう便利になったのか複雑怪奇にしただけで便利さや機能の優れている点等どこにも見えない。VB6の便利な機能排除の主な物は以下の通り。 Inetコントロール、Winsockコントロールの排除、コントロールの配列機能排除、ポップアップメニュの左クリック排除、フォームのUnloadの排除等等 その他枚挙にいとまない。またこれを代わりの方法で実現する方法等本にも書いてない

この記事は「Theorem Prover Advent Calendar 2013」6日目の記事です。 http://qiita.com/advent-calendar/2013/theorem_prover 神田「野らぼー」にて、地下の薄暗い店内で… 「そう言えばこないだ隣で起こってたポインタオーバーラン、対応大変そうだったですけどちゃんと家に帰れてたんでしょうかね、新婚なのに…」 「ヌルポとかポインタオーバーランとか、どうして無くならないんだろうね。その時はみんな手を抜いてるつもりなんて毛頭なくて、一生懸命考えて大丈夫だと思ってるはずなんだけどね。レビューもして、それでも起こった後でみんなでソース見てみると、なんで気づかなかったんだよ!ってことになる。」 「人間って、そういうの苦手なんでしょうねきっと。ほら、『何かほかにありませんか』って聞かれても出てこないじゃないですか。静的な解析っ


出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない


僕はプログラマーです。 でも僕のMacBookProには何故かAdobeのソフトウェアが入っています。iPhoneアプリのデザインをするわけではありません。 デザイナーの人がデザインファイルを.psdや.aiや.fw.pngのまま当然の様に投げて来るからです。 僕はAdobeのソフトウェアに精通しているわけではありません。 ですので複雑なレイヤー構造のファイルを切り出すのにはかなり時間を要します。 でもレイヤー構造の説明をしてくれるデザイナーの人は殆ど居ません。 デザイナー同士だとその複雑な構造でもやり取り出来るのかも知れませんが、僕には大抵よく分かりません。 例えば、Photoshopのエフェクトレイヤーが掛かっているボタンはボタンだけ切り出す時に凄く苦労します。 例えば、薄くシャドーが掛かってるデザインは素敵な質感を表現出来るかもしれませんが説明してもらわないとどこまで切り出したら良

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く