富豪的プログラミング
ちょっと貧しいGUI ユーザインタフェースのプログラムといえばすっかり グラフィカルユーザインタフェース(GUI)があたりまえになりました。 ところが最近の計算機はメモリもディスクも大量に装備しているし CPUパワーも従来とは比べものにならないのに、 意外と貧乏臭いインタフェースが生き残っているようです。 よく見られる以下のようなインタフェースはちょっと貧しい と思われます。 ウィンドウ枠のドラッグ マウスでウィンドウを動かそうとするとき、 ウィンドウの枠だけマウスに追随し、中身はドラッグ終了後に 再描画されるというシステムがあります。 画面描画が遅かった時代はこういう工夫も仕方がなかったかもしれませんが、 今でもこういうインタフェースを使っているのは貧しいでしょう。 排他的論理和で枠を書いたりもとに戻したりしていれば貧しさ度アップです。 でも調べてみたら同僚のほとんどが 枠だけドラッグの
スーパーファミコンのプログラムを書きたい - ポルノアニメ
2016/04/06追記 はてなブックマークの「一年前の話題」だとかでやたら人が来てたので、一年前の一年後（つまり今）の状況を記しておきます。 ↓ http://gyuque.hatenablog.com/entry/2016/03/28/215253 今年はSFC 25周年である。大学ではなくスーパーファミコンのことである。 @pornanime いいからスーファミでピコピコしてろよな。— カザオカマリ (@ykzts) March 16, 2015 スーパーファミコンを買ってもらったのは小学校に上がった頃か、日焼けして真っ茶色になってはいるが未だに動作し、手元に置いてある。共に育ったマシンなので美しい思い出を語っては上のように若造に馬鹿にされているのだが、よく考えるとこれだけ思い入れの深いスーパーファミコンで動くプログラムを書いたことはなかった。プログラマーとしてこれは誠実ではない、と
新卒ソフトウェアエンジニアのための技術書100冊 - クックパッド開発者ブログ
こんにちは、技術部 高井です。 春といえば、フレッシュマンの季節ですね。このブログを読む方の中には、明日からエンジニアとして新社会人になるという方もいらっしゃるのではないでしょうか。クックパッドでも新しい仲間を迎えるための準備をしていたところで、その準備の一環として「新卒ソフトウェアエンジニアのための技術書100冊」というものを作成しました。 この100冊は、職業ソフトウェアエンジニアとしてキャリアを積むにあたって、読むべき技術書に悩んだら、まずはこのリストから選ぶとよいのではないでしょうかという提案です。 リストに多少の趣味や主張がはいっているのは、まあご愛嬌ということでお許しいただければとおもいますが、職業プログラマとして知っておくべき知識を網羅できるように心がけました。古典と呼ばれる名著についてはできるだけ取りいれ、独習が難しい難解なコンピュータサイエンスの教科書は避けています。これ
スタートアップや新規事業に限った技術的負債の考え方 | F's Garage
最近のエンジニアの感覚だと、技術的負債というのを極端に嫌うケースがあるそうですね。 技術的負債とは… 行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。 wikipedia – 技術的負債 この言葉は確かにキャッチーだ。プログラムなんて動けばいいでしょという上司に楯突く時に使いやすい武器になりそうだ。 「負債」という言葉はなかなか面白い比喩である。 では少し、負債という言葉について調べてみると、こういうのが見つかる。 負債は借入金や買掛金などの法律上の債務であるとイメージされがちですが、厳密にいったらこれは間違いです。 すなわち負債とは、法律上の債務に限らず、いずれ会社が負担することになるであろう経済的負担で貨幣額で合理的に評価できるものが該当します。 http://financial.mook.to/accounti
静的型付き言語プログラマから見た動的型付き言語 - あどけない話
およそ20年前にAlan Kay の講演をきいたことがある。印象に残ったのは、彼が引き合いに出した McLuhan の言葉だ。 I don't know who discovered water, but it wasn't a fish. (拙訳)誰が水を発見したかは知らないが、発見者が魚でなかったことは確かだ。 誰しも信念という水の中を泳ぐ魚のような存在だ。思い切って飛び跳ね空気に触れてみなれば、自分が信念という水の中にいることに気付かない。 ある手法の利点を語るには、その手法の欠点や、他の手法の利点や欠点とできるだけ客観的に比較しなければ説得力がない。ただ、これを実践するのは難しい。この記事では、客観的になれているか自問自答しながら、動的型付き言語と静的型付き言語について比較してみようと思う。 僕は静的な C 言語から、動的な Perl、Lisp、JavaScript を経て、現在で
コンピュータシステムの理論と実装
TOPICS 発行年月日 2015年03月 PRINT LENGTH 416 ISBN 978-4-87311-712-6 原書 The Elements of Computing Systems FORMAT コンピュータを理解するための最善の方法はゼロからコンピュータを作ることです。コンピュータの構成要素は、ハードウェア、ソフトウェア、コンパイラ、OSに大別できます。本書では、これらコンピュータの構成要素をひとつずつ組み立てます。具体的には、NANDという電子素子からスタートし、論理ゲート、加算器、CPUを設計します。そして、オペレーティングシステム、コンパイラ、バーチャルマシンなどを実装しコンピュータを完成させて、最後にその上でアプリケーション（テトリスなど）を動作させます。実行環境はJava（Mac、Windows、Linuxで動作）。 ● 本書のサポートサイト ● 本書で使用する
2015年の最優先事項は関数型プログラミング！ | POSTD
—もはやOOP（オブジェクト指向プログラミング）は”クラウドモンスター”から私たちを守りきれない おそらくあなたは、”Clojure”、”Scala”、”Erlang”といった言葉や、”Javaにラムダ式が導入された”という話を聞いたことがあるでしょう。そしてそれらの言葉が”関数型プログラミング”と関連があるのをご存じかもしれません。プログラミングコミュニティに参加していれば、おそらく既にこのテーマが議題に上がっているでしょう。 Googleで”関数型プログラミング”を検索しても、目新しいものは何も見つかりません。言語の中で2番目に古い言語は、関数型プログラミングを利用しています。1950年代に登場した、Lispという言語です。では一体なぜ人々は、今になって関数型プログラミングに沸き立っているのでしょうか？ およそ60年も経っているのに？ 初期の頃、コンピュータは実に遅かった 信じられない
なぜ採用される言語とされない言語があるのか | POSTD
私の 前回の記事 では、 Heartbleed バグを早めに見つけられないことは、ある意味で改良とデプロイの失敗となると論じました。そうでなければ、これは静的解析にとって効果的なテクノロジーです。特に、商業的な静的解析ツールは故意に潜在バグを無視しますが、これは間違ったアラームが大量に報告されるのを避けるためです。つまり、健全性よりも完全性が好ましいということです。このようなツールを作る企業は、利益になるサービスを好況市場に提供することを狙いとしており、彼ら独自の調査では健全性は売れ行きに関して重要ではないということが示されています。その代わり、生き残るためには、本当に重要なバグを開発者が効率的に発見する手助けになるツールでなければいけません。全てのバグの検出は必要ないのです。リサーチャーの挑戦は、効率（それと、その他の望ましい基準）を維持しながら、健全性に背を向けてビジネス案を推進する方
「関数型言語」に関するFAQ形式の一般的説明 - Qiita
前置き： 特定の言語ではなく、関数型言語一般に関する説明です。 ここに書くのが良いのかわかりませんが、それを考える時間ももったいないのでとりあえず書きます。必要が生じたら移転します。 皆様のご要望や自分の気分(?)により随時加筆修正します。 「それは違うんじゃない？」というご指摘はもちろん、初心者の方の素朴な疑問・質問や、「ここがよくわからない」「こういうことも書いてほしい」みたいなコメントも歓迎します。すぐに対応できない場合もあると思いますがすみません。Twitterのesumii宛でも構いませんが、コメントのほうが他の方も見つけやすくて良いと思います。当然ながら（他者に対しても）誹謗中傷等はご遠慮ください。 いただいたコメントはほぼ本文に反映していますので、本文を読むために、必ずしもコメントを読む必要はありません。もちろん、興味と余裕(?)があればコメントも読んでいただければ非常に有用
新人プログラマに正月休み中を使って読んでみてほしい技術書をセレクトしてみた。 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 今年、書いた幾つかの記事のタネ本であったり、新卒教育の際に参考書籍
社会人10年目から始める競技プログラミングのすすめ - kuuso1のブログ
これは、Competitive Programming Advent Calendar 2014の17日目の記事です。 競技プログラミングという世界を知って1年がたちました。結構飽きやすい性格の自分が1年ほどコンスタントに参加するという充実したプロコン（プログラミングコンテスト）ライフを送ることができた記念に、これからプロコンに参加してみようという方向けの記事を書かせていただきます。CPAC2014参加諸氏のような技術的に高度な内容は残念ながらなさそうですが（書けるものなら書きたい）、10年目エンジニア的視点で自分が感じたことを踏まえて「これはいいものだ」と思えたところなどを中心に振り返ることで、なんとかタイトル詐欺を回避したいと思います。中盤はお目汚し感が強いかも。。 経緯や参加したプロコンなど 半導体関連のメーカーで開発の仕事に従事していますが、2012年に職場都合で富山県に引っ越すこ
書類仕事を追いかけて - steps to phantasien
大きなコードベースの真ん中あたりをさわっていると、仕事の大半はリファクタリングに費やされる。機能を足そうと書くコードも 8 割リファクタリングで新緑は 2 割。失敗して捨てるものも多いから、かける時間は 9 対 1 くらいかもしれない。 それどころかリファクタリング自体がプロジェクトにもなりうる。「今四半期はこの腐ったコードどもをなんとかするのが目標」というように。私もいま大きなリファクタリング、あるいはリアーキテクティング、の手伝いをしている。仕事時間のほぼすべてがリファクタリングに費やされる。今の勤務先で通用する唯一の特技がリファクタリングな私にとってこれはたぶん適職だ。 リファクタリングにコーディングの大半を捧げる人は他にもいる。 プログラマ相手の管理職をエンジニアリング・マネージャと呼ぶ。ほぼ全員プログラマ出身。現場に近いマネージャは多くがコードも書く。ただ血気盛んな人を除くと新機
Reactive Porn - steps to phantasien
Rebuild.fm に出させてもらいました。ありがたいことです。 さっそく録音を聞き直す。自分の声を聞くのは辛い・・・のはさておき、 リアクティブプログラミングの話は我ながら主張がよくわからない。 反省のため何が言いたかったのかを考え直したい。 たぶん趣旨は二つあった: A. RxJava や RxAndroid はなかなかいいやつだ。 B. リアクティブプログラミングは一つのはっきりした概念ではない。 A については試してもらえばわかるはず。ReactiveX のサイトからぽつぽつ資料を読めば済む。ここでは B を補足してみる。 X 指向は Y みたいなもの リアクティブプログラミングとは何だろう。どうもつかみどころがない。私は腑に落ちるまでけっこう時間がかかった。 このわかりにくさには大きく二つ理由があると思う。一つはプログラミングの概念をコードなしに説明する一般的な難しさ。オブジェ
一ヶ月、Rubyを本気で独学した結果（文系向け） - 30ruby記
まともな文章にしたいのだけど、そうする余力がないので、記録のために箇条書きでメモ書きを残します。独学でRuby (on Rails）を学ぶために、まず初学者向けのまともな情報が少ないし、僕以上の事例はそういないと調べて思ったのと（自分で言ってすみません）、これから学ぶ人が増えるだろうから、その参考になればとも。 2015年5月20日 追記 → ※採用できたため募集終了。ありがとうございました。 開発メンバーを募集しています。意欲と能力を兼ね備えた若者を歓迎します。スキルは、この記事を書いた当時の僕くらいあればokです。 30ruby.hatenablog.com 2017年11月23日 追記 フロントエンジニアを募集します！やる気があって、実務経験あって、EdTechの本命として教育を根本から変えていくというミッションに共感していっしょに走ってくれる方を探してます！ www.wantedl
プログラミングの勉強で重要だなとおもったこと
１、あらゆる意見について盲信してはいけないインターネット上ではとりわけ多いけれど、ある意見を適当に述べている人というのは多い。適当に述べている……とは、別に悪気があってそうなったわけじゃなくて、本人もよくわかっていないけど「なんかうまくいったからとりあえずブログに書いた」風のものがあるということだ。例えばブログに書いてあったソースをそのまま貼付けてコンパイルエラーになることがあるけれど、それには色々要因があって「本人がブログ上で書いたまま検証していない」「サイト上でレイアウトが崩れた」「環境が違う」等いろいろある。自分のわからないものに関しては「そうなんだ。まぁとりあえずそういうことにしておこう」ぐらいでいい。断定口調で「絶対こうだ」と書いている人も、間違っていることが多々ある。それは本でもそうだ。「ほんとうかなぁ？」と思ったら疑った方がいい。自分しか信じてはいけないし、その自分すら疑った
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラムを高速化する話
長文日記
https://qiita.com/tokomakoma123/items/a33feffe947a958a2d3a
「型を付けないほうが自由？」抽象化と型の関係について
新鋭の言語: この5年を振り返る
