はじめに 2月16日にComputerCraft1.7がリリースされました。 Just released ComputerCraft 1.7! Featuring the brand new Command Computers. http://t.co/GMS6CJGqKB— Daniel Ratcliffe (@DanTwoHundred) February 15, 2015 さあ、ダウンロードしてインストールしましょう。 なお、Minecraft1.7.10用ですのでご注意を！ ComputerCraft | Programmable Computers for Minecraft なにが新しいの？ 念のためWhat's Newを適当和訳しておきますね。「」内は僕のコメントです。 コマンドコンピュータ（Command Computer）を追加 「使えるのはクリエイティブモードだけです」

はじめに さっさとマイクラ、ComputerCraft関係の記事を書け？ はい、ご指摘ごもっとも。 とはいえ、最近はプログラミング教育についても興味があります。 自分の考えの整理も兼ねて文章を書いたので、ここで公開させてくださいな。 なお、ひたすら長いので、「まとめ」だけ読んでいただいてもかまいません。 今回の記事の元ねたはこちら。 元ねた記事のまとめ（僕の独断と偏見によるもので異論は認める） いろいろ問題となっている武雄市のタブレットを用いた教育ですが、子どもが使っている掛け算練習ソフトを見たら画面の片隅にバナー広告が入っているじゃない。これって大丈夫なの？ 一概に広告に反対するわけではないけれど、武雄市は何も考えてなさそう、まずいでしょう。 武雄市の教育に対するネット上の言論について 武雄市のタブレット教育について、そのやり方や問題点の洗い出しなどネット上では議論が活発に行われています

はじめに 中学生たちに「なぜプログラミングが必要なのか」を教えてみた - WirelessWire News（ワイヤレスワイヤーニュース） この記事を読んでの感想になります。 将来的に3Dプリンタが家庭内で普通に使われる時代には、きっとプログラミングの必要ないUIができているはずです。 テレビがリモコン一つで操作できるように、電子レンジが前面のパネルボタンだけで操作できるように、炊飯器がボタン一発でおいしいご飯を炊くように。逆にそうでないと、家電として家庭内に3Dプリンタが普及するわけがありません。 しかし、テレビのリモコンボタンの数が増え操作が複雑になる一方であることからわかるように、シンプルなUIで家電の機能の全てを引き出すというのは無理があります。 紹介記事中にある、 プログラミングをできるようになるということは、人類の叡智を利用できるようになるということ は至言です。 プログラミン

ソフトの概観とダウンロード version0.1の公開を停止し、version0.2を公開しました。詳しくはこちら。 ニンジャコピペだと、このくらいのパラメータが好きかも・・・ pic.twitter.com/GJQMxrPjHi— 確実にへぼへぼ (@hevohevo) 2014, 7月 28 VoiceTextApp. version 0.1 作った人： hevohevo (Twitter: @hevohevo、http://hevohevo.hatenablog.com/） 絶大なる感謝を： HOYAサービス株式会社 VoiceText Web API（https://cloud.voicetext.jp/webapi) このソフトについて このソフトは、 HOYAサービス株式会社さんのVoiceText Web API（β版）を利用した、 入力テキストを読み上げるソフトであり、実質

あたらしくワールドを作り直しました 色々と思うところあって、ワールドを新しく作り直しました。それに伴って、Mod構成も見直し。 特に、1.6.4版Greg-tech（gregtech408s）のひどさに閉口して、Gregはやめることにしました。 - ひどさの例 - 電子回路の作成に赤石合金が必要。 - 赤石合金の作成にはマシンが必要。 - そのマシンの作成に電子回路必要。　詰んだ＞＜ - さらに、MekanismのControl Circuitのレシピを上書きしてGreg電子回路と同じにしているものだから・・・。 難易度上げるために必要材料を変えるのはともかくとして、詰んだ状態のまま放置してバグ修正しないというのはさすがにきついです。 上記は僕の勘違いだったようです。 しかしGreg-techやめると快適ですねぇ。WoodからPlank4個できる。Plank2個からStick4本できる。こ

APIが様々なプラットフォームで提供され、様々なサービスで活用される今日。そんなAPI経済の状況をわかりやすくまとめてくれた記事をThe Next Webから。 — SEO Japan アダム・ドゥヴァンダーは、SendGridでディベロッパーコミュニケーション部門を統括する、「開発」のスペシャリストである。過去には、Wired、Webmonkeyに記事を寄稿し、また、APIのリソースとして名高いProgrammableWebで編集に携わった経験を持つ。 数年前、アプリケーション・プログラミング・インターフェース（API）は、楽に、そして、機能的にアプリケーションを連動させるための手段、つまり、デジタル版の接着剤と認識されることが多かった。しかし、現在、APIの価値は、単なる橋渡し以上の役目に進化している。 多くの開発者にとって、APIは、ビジョンを明らかにすることが可能な基礎的な構造の役

前回のおさらいと今回の話 前回は手続き型パラダイムとオブジェクト指向パラダイムを見比べたときに、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめて守る」という方向に言語が進化していったというひとつの史観を示しました。その中で返答として「構造化プログラミング」の時点でその視点はすでにあるという指摘を頂いたりもしました。ただ、「ひとかたまりのデータとそれを操作する手続きを一カ所にまとめる」という発想もオブジェクト指向の「ひとつの側面としては」たしかにありますし、その側面を見ると、オブジェクト指向言語に「言語デザインでもってプログラマーがそれを行いやすくした」という面を見いだすことができそうです。そして、その視点に立ったときに「臭ってくる」ヤバい設計として、「データが露出してる」「別のクラスのデータいじってる」「複数の異なるデータに関心をもってしまっている」というものを挙げてみました

TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん