プログラミングの本質とは - 射撃しつつ前転 改
プログラミングの本質は、条件分岐と繰り返し（と連接）だけでチューリング完全が実現できることであると考えている。つまり、いわゆる構造化定理である。 プログラミングの勉強を始めた頃は、一体どこまで勉強すれば自分はプログラミングが出来るといえるのか、まったくわからなかった。構造化定理を知ったとき、ああ、これだけ知っていれば全てのプログラムが書けるのか、と感動したし、振り返ってみても、あの瞬間はプログラマとして一つの到達点であったと思う。もちろん、そこから先の道のりは、まだまだ長かった訳だけれども。 構造化定理の良い点は、チューリングマシンというなんだか抽象的かつ重要そうなものと、自分がいつも書いているプログラムの間をシンプルに結びつけてくれる点であると思う。実際にプログラミングをする際の道具立てとしては便利なものが色々とある（高階関数だとかクロージャだとかね）訳だけれど、精神を支えているという点
OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
![OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/04e015dad70084a57fdfa9a2686c0c93441c5d2d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128193858%2F1557447212)
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
Makefileの書き方 - スキルアップ輪講
makeって何？ † ソースファイルを分割して大規模なプログラムを作成していると、コマンドでコンパイルするのが面倒です。また、一部のソースファイルを書き換えただけなのに全部をコンパイルし直すのは時間の無駄です。 そんな問題を解決するのがmakeです。Makefileと呼ばれるテキストファイルに必要なファイルと各ファイルのコンパイルのコマンド、ファイル間の依存関係を記します。そして、“make”というコマンドを実行するだけで、自動的にコマンドを実行してコンパイルしてくれます。これだけではスクリプトと大差がないのですが、makeはMakefileに記された依存関係に基づいて更新されたファイルの内関連のあるものだけを更新することで、コンパイル時間を短くします。 makeは特定のプログラミング言語に依存したものではありません。C言語のソースファイルのコンパイルにも使えますし、Verilog-HDL
はてなブログ | 無料ブログを作成しよう
うめぇヨーグルトソースでもいかがですか。個人差にもよりますが。もしよろしければ。 お久しぶりです。 最近うんめぇ〜と思ってるヨーグルトソースがあるので、書いていこうと思います。 ヨーグルトとハーブ類をもりもり使うので、そういうのが食べられない方にはうんめぇソースではないです。ごめんなさい…。もしよろしければお茶だけも…旦~ 【用意する…
ひなた先生が教えるデバッグが256倍速くなるテクニック - higepon blog
id:yaneurao さんにひなた先生が教えるデバッグが256倍速くなるテクニック を献本いただきました。ありがとうございます。 連載当時に数回レビューさせていただいた事があったのでそのご縁。 今読み返してみると、自分が二分法によるバグ原因特定を明確に意識したのは、この本からだったことが分かる。それ以前は、経験的に有用性に気付いていたもの、積極的に使ってはいなかったのだよなあ。半自動的にバグを見つけるとかもそう。 この本は表紙の絵が摩訶不思議な雰囲気で手に取るのを躊躇するかもしれないが、個人的には特に前半が勉強になる人は多いと思う。 バグの原因特定までの基礎的な道のり スタックを覗いてみる など、デバッグには多くのテクニックがあるのだけど、そういった基礎を学べる。 ちなみに泥まみれで、たくさんデバッグしてきた以下のような経験のある人には易しすぎるかも。 gdb でデバッグしようにも自分の
人生いろいろ、技術者もいろいろ、搾取されないに越したことはないよね - 雑種路線でいこう
受託調査＆研究補助→ユーザー企業コンサル→通信事業者コンサル→Web企画構築→金融SE→研究・コンサル→パッケージベンダ・マーケ→パッケージベンダ・技術渉外のおいらが来ましたよ。 こんなことをいっては「上流」にいる方々には失礼かもしれませんが、IT業界は上流にいるほど得になるような構造になっています。それぞれのプロジェクトについて自分のところで十分な経費を確保してから下流に流しますので、下流にいるほど仕事がきつくなります。それをうすうす感づいているから、若い人は少しでも上流に行きたがります。PGをしばらく勤めたらSEに、SEを少しやったらコンサルに。産卵まぢかの鮭でもあるまいに、自分の技術レベルも分からないまま、やみくもに次のステップを目指そうとする。 実はプログラムを書かなきゃいけない仕事ってやったことないんだけど、Web企画構築の時はベンチャーで大手ISPに提携を申し入れ「お前らに顧客
inforno :: Python2.6変更点まとめ
Python2.6きましたね。ということで、自分用にも主な変更点メモ。なぐり書きなのでミス多いかも。個人的な注目部分は with文 multiprocessing itertoolsへのメソッド追加 ABCの導入 クラスデコレータの導入 ネットワーク系ライブラリ(http,ftp,telnet..etc)でタイムアウトが設定できるようになった。 あたりですかね。ではどうぞ。 Python 3.0由来の変更点 複素数へオブジェクトを変換する __complex__ メソッド。 例外補足のためのもう一つ書き方： except TypeError as exc build-inの reduce() に加え、 functools.reduce の追加。(3.0では reduce はfunctools経由でしか使えない) 3.0では他にもbuild-in関数に変更がある。3.0互換のコードを書きたい
2008-10-01 - 兼雑記 ■[Program] デバッガとスレッドとイベント
実行パスが一つしか無くて、ユーザやらネットワークやら、外部とのインタラクションもブロッキングして読んで問題ないようなプログラムならいいんですが、まぁなんかそうもいかないことも多く、そういう時はスレッドやら select/epoll やら使ってごにょごにょしてるわけです。でまぁ、あろはさんのとこのコメント欄を荒らさせてもらったんですが、まぁデバッガに欲しいスレッドやらイベントサポートの話。なんとなくもやもや思ってることを適当にまとめてみます。 まずまだマシなスレッドの方。まぁ適当に 100 スレッドくらいのスレッドプールの中の一つのスレッドが SEGV したとする。さあデバッガの出番。とりあえず適当に現在のスレッドの値を調べてみたところ、なんかおかしな値が入ってたとします。でまぁ、シングルスレッドでバグが無いとしたら、レースコンディションです。でそいう時にとりあえず、 thread appl
![2008-10-01 - 兼雑記 ■[Program] デバッガとスレッドとイベント](https://cdn-ak-scissors.b.st-hatena.com/image/square/b978c5bdeb221158433e1bf43f86027422246c8a/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673860805%2F8454420450066433267%2F1411772550)
Erlang実験室：例外的値とバリアント型データ - 檜山正幸のキマイラ飼育記 (はてなBlog)
久々にErlangネタ。 Erlangにも、throw-try-catch方式の例外機構が備わっています。ですが、例外機構を備えた他の言語に比べると例外を使う機会が少ない気がします（印象、統計的裏付けはない）。ひとつの理由として、軽量プロセスの終了シグナルを使ったエラー処理が使えることがあるでしょう。また別な事情としては、例外ではなくて例外的値が非常に手軽に使えることが影響しているようです。 Erlangにおける、例外的値を使った処理 例えば、次のような仕様（構文は便宜上Java）の関数fooを考えます。 void foo(Object message) throws FooException; Erlangだと、この程度のことなら例外を使わずに、エラーを示す値を使ってしまいます。そのような、例外的値を持つ関数仕様をElrangの記法で書くと次のようになります。 @spec foo(Mes
Erlang実験室：武士道と云ふは死ぬ事と見付けたり - 檜山正幸のキマイラ飼育記 (はてなBlog)
Erlangでは、「死ぬこと＝プロセスをクラッシュさせること」の解釈／意義／価値観が、他の言語とは随分違います。潔＜いさぎよ＞く死ぬことが推奨されていますが、これは責務の放棄とは違います。 内容： 事故や災害への対処は個人ではなくて企業や社会が行うべき 正常と異常のはざま 例外を使うのは例外的？ 多プロセス並列プログラミングと例外 潔さと無責任は違う -- 武士道プログラミング ●事故や災害への対処は個人ではなくて企業や社会が行うべき Erlangの書き方や文化で、なかなか馴染めないのが「異常時の処理を書かない」という方針です。 多くのプログラミング言語のコードでは、次のような分岐をしばしば見受けます。 if (正常条件) { 正常時の処理; } else { 異常時の処理; } switch (値) { case 正常な値_1 : 正常時の処理_1; break; case 正常な値_2
プログラマとして生きるということ
システムエンジニア、プログラマーなどにおける過酷な労働条件を自嘲的に表現したもの。「土方」は差別用語及び放送禁止用語として扱われているため、使用の際には留意すること。 という意味だそうです。僕は研究者だけれど、プログラマでもあるので、プログラマが世間でこう呼ばれているのは非常に悲しいことです。プログラマというのは、本当はとても魅力的な仕事です。土方で甘んじているのは、きっと「プログラマ」として生きていないのだとも思います。（例えば、矢野勉さんのエントリにも挙げられているような状況の人達です） プログラムをデザインする、ということ プログラムの場合、通常の土木工事と比べて顕著に違うのが、一度作ったコードを「一から作り直さないようにデザインできる」ということ。たとえば、コマンドライン引数を処理するプログラムを一度作ると、それをクラスの形に整理して（OptionParserクラスなどと名づけて）
Cowboy Programming » Debugging Memory Corruption in Game Development
Definition: Memory corruption is an unexpected change in the contents of a memory location. The symptoms of memory corruption can range from hard crashes, all the way through minor glitches, to no symptoms at all. The causes of memory corruption are many and varied, and include memory corruption itself.  In this article I attempt to classify the various ways in which memory corruption can man
マルチコア時代の高速サーバーの実装 - Blog by Sadayuki Furuhashi
特にサーバー用途では、CPUがシングルコアに戻ってくることは考えにくい。 マルチコアCPUの性能を活かすにはマルチスレッドに対応したサーバーの実装が必要になるわけですが、マルチスレッドなプログラミングは往々にして「高負荷になると固まる」とか「たまに落ちる」といった悩ましいバグと戦わなければならず、イヤです。 かといってシングルスレッドでは、近い将来 32コアCPU! などが出てきたとき、たぶん性能を発揮できません。 そこで、そこそこデバッグしやすく、それでいて多コアCPUでもスケールするという落としどころを模索しているのですが、ボトルネックはネットワークIO周りにあるだろう*1という前提の元で、ネットワークIO部分だけをマルチスレッドで動かし、それ以外の部分をシングルスレッドで動かすというアーキテクチャを考えています。 ロジックの部分はマルチスレッドで書いても共有リソースにアクセスする度に
記号だけで brainfuck インタプリタ - まめめも
Ruby 1.9 の新機能のひとつに「lambda { ... } を -> { ... } と書ける」というのがあります。この表記は反対意見が根強い *1 ですが、確実にすばらしい点があって、全部記号だということです。これによって Ruby が記号だけでチューリング完全になります *2 。 デモとして、brainfuck インタプリタを記号だけで書いてみました。 $___,@_,@__,$_=(@@__="")=~//,?#=~/$/,->(_){_<(__="####"=~/$/)**__&&(@@__<< _;@__[_+@_])},[*$<]*@@__;@__[$___];$____,$_,@___,$__,@__=$_[@_+($_+?!=~/!/ )..-@_],$`,[],[],->(_){(__=$_[_];__=~/[><+\-\.,]/?$__<<$_[_]:__==?
いいコーディング規約、悪いコーディング規約？ | スラド デベロッパー
本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。 可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか？ ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか？ /.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか？ 逆に規約のせいで問題が起きてしまったケースなどあるだろうか？ 他にも、使える「自分ルール」などもあれば是非。
Javaの型推論Utilsクラスのカラクリ
Javaの型推論Utilsクラスというエントリで Listなどのジェネリクスの型パラメータを省略する方法が書かれています。 // 型推論で空のインスタンス作成。 // 変数の型と値の型、同じ物を２回書かなくてOK。 ArrayList<String> strs = list(); HashMap<String, Date> dateMap = map(); HashSet<File> files = set(); 気になるlist()の実装は public static <T> ArrayList<T> list(T... items) { return new ArrayList<T>(Arrays.asList(items)); } といった感じ。 通常は代入時にジェネリクスの警告が出る ジェネリクスの型パラメータを指定しない場合、代入の際に安全な代入ではないと警告されます。例えば L
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Index of /docs/AMD
IBM Developer
IBM Developer