はてなブックマーク

IT業界には「奥が深い症候群」って言葉があってな 使いにくいシステムを使いこなすことに喜びを感じて、使いこなせない人間を見ると罵倒する そういう人が幅を利かせていつまでも改善がされない そんな症状だ https://anond.hatelabo.jp/20200603093957 ソフトウェア・エンジニアが使うツールには、使い勝手の良くないものが割と存在する。その辺の事情に関してはバッドノウハウと「奥が深い症候群」で語られている内容が詳しいのだが、必ずしもそれが全てではない。 例えばGitは、まあ15年ほど開発が続けられているツールではあるが、それでもどちらかと言えば後発のバージョン管理システムだ。しかしオープンソースの有名どころバージョン管理システムを歴史順に「CVS・Subversion・Git」と並べた時、Gitは最後発なのにも関わらず、使いこなせないというユーザは最も多いように見え

ふむ。 量産型プログラマを撲滅したい – Yoshihito Kuranuki – Medium 最近、量産型プログラマに遭遇したのだが、彼らを観察しているうちに、量産型プログラマとそれ以外のプログラマとでは、次の点に違いが見られることに気づいた。 ソースコード・ドキュメント・「『デバッガ上でのプログラムのふるまいや、テストデータを食わせた時の挙動』の観察から得られた知見」などから、対象システムについての一貫性のあるメンタルモデル／概念モデルを、頭の中に構築することができるか否か？ 頭の中に構築したメンタルモデル／概念モデルが、実際のシステムと比較して、妥当なものであるか否か？ 頭の中に構築したメンタルモデル／概念モデルが、実際のシステムのそれなりの範囲をカバーしているか否か？ 頭の中に構築したメンタルモデル／概念モデルに基づいて、理路整然と議論や推測を行うことができるか否か？ 頭の中に構

やあ、ようこそ職業プログラマの世界へ！ この文書は、何の準備もなくコの業界に飛び込んでしまった文系プログラマ（候補）や、将来的にコの業界に就職するかもしれないし就職する気もあるけど基礎が足りてないと自覚している学生に、比較的短期間で商品知識以外の職業プログラマの技術的基礎を叩き込むための技術書のリストだ。対象が対象だけに、そこそこやさしめかつ極力高くない本を選んでいるつもりだ。*1 比較的短期間ってどのくらいか、だって？　驚くなよ、3年だ。 ――えーと、3年なんて長すぎる？　またまたご冗談を。10日間とか半年で何となかるだなんて信じてもないくせに。それぐらいで何とかなるのは、それなりに下地のある人か、非常に才能に溢れている人ぐらいなのよ。これを読んでいるあなたが、そんな一握りの人たちの仲間だというなら、それは非常に喜ばしいことだよね。でもそういう人はごくわずか。世の中は「自称『普通の人』」

シェルスクリプトについて、プログラミング言語の一種としてガッツリ学んだうえで、しかし得手不得手を見極めて、無理せずシェルスクリプトらしい使い方にとどめて日々を過ごしたい人のための10冊を選出すると、だいたいこんな感じとなる。 前提として「他の言語でのプログラミング経験あり」「コンソール／ターミナルに多少なりとも慣れている」人が対象。 『入門UNIXシェルプログラミング　改訂第2版』 『UNIXプログラミング環境』 『シェルプログラミング実用テクニック』 『実践ユニケージ開発手法01　コマンド学習編』 『実践ユニケージ開発手法02　シェルスクリプト学習編』 『実践ユニケージ開発手法03　Web アプリケーション編』 『Windows/Mac/UNIXすべてで20年動くプログラムはどう書くべきか』 『プログラミング言語AWK』 『sed & awkプログラミング　改訂版』 『sed & awk

身辺整理というか、開発用機材の入れ替えだ。新しいPCに移行するので、返却する古いPCのHDDデータを削除する必要があるのだ。 今まではWindowsだけで、しかも1回に1台のPCだけで済ましていたというのに、なぜか今回はWindows・Mac・LinuxのオールスターPC軍団（5台ぐらい）のデータを削除する必要があるという。ツケってもんは、実に恐ろしいですなあ。 Windows Windowsの標準機能では、セキュアにファイルを削除する方法はないようだ。そこでWindows SysinternalsのSDeleteを使う。 :: 指定したファイルを削除（7回上書き） sdelete -p 7 target-file :: x86-64向けにsdelete64もある sdelete64 -p 7 target-file :: 指定したフォルダの中のファイルを再帰的に削除（7回上書き） sde

C言語で書かれた大量のソースファイルをサンプルとして、現実でのgoto文の利用方法について調査した研究の結果が発表されたようだ。 C言語の開発者によるgoto文の使い方を対象とした実証研究の結果、「goto文は無害だと考えられる」 | スラド Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful" - Slashdot An empirical study of goto in C code [PeerJ Preprints] とりあえず、歴史的経緯的に非常に重要だろう指摘をしておくと、ダイクストラの「Go To Statement Considered Harmful」が出たのが1968年で、C言語の初期の設計・開発が行われたのは1969〜1973年だ。C言語は、ダイクストラの論文が大きな話題となった後に

ちょっと前の記事だけと、少し気になったので書いておく。 誰もが知ってるけど敢えて言わない確実に身につくプログラミング学習法 - WirelessWire News（ワイヤレスワイヤーニュース） 要約するのが面倒なので、内容については上記記事を参照してもらうとして……以下、上記記事を読んでいるという前提で、色々と省きながら書く。 上記記事では、プログラミングの上達にて効果的な手段として「写経」を挙げている。といっても、単なる写経ではなく： そして筆者自身も、新しいことを勉強するのに、サンプルプログラムをとってきて改造するのをやめて、サンプルプログラムを一度印刷し、一言一句、上から下まで写経すると、驚くほどコードへの理解が深まることに気づきました。 なぜかというと、写経というのは、「なにも考えなくて良い」と言われるものの、人間ですから考えてしまいます。しかも、一言一句、記号のひとつひとつまで、

「コメントの書き方」にもある種の理論・思想があり、理論・思想にもとづく「型」があると思っているのだが、「『コメントの書き方』についてそこまで突っ込んだ理解をしている人は驚くほど少ない」と考えておいたほうが無難だろう。 Code Kataは既出だが、Comment Kataは無い。しかし「型」はある。見落とされているだけだ。 ――と、下記エントリとその周辺を見ていて思った。 【プログラミング】退職した先輩が書き残していったコメントがひどすぎる・・・ - 私の戦闘力は５３万マイクロです http://nzmoyasystem.hatenablog.com/entry/no_comment_culture それはおそらく、コードは動作するが、コメントは動作しないからだろう。コードは主役であり、コメントはパセリだ。ともなれば、我々はコードの品質向上については気にかけるが（なんたって主役なんだから！

※2015/11/15追記：現段階では8言語から12言語に増えている。 その昔 id:eel3:20120129:1327845759 なんてことをやったのだが、性懲りもなくまた同じようなことをやってみた。 作ったものはこちらに置いてある。 GitHub - eel3/hcasl: Command line tool for "head -c N && shift 1 byte/char" loop どんなツールを作ったかというと、テキストファイルの先頭から指定したbyte数（または文字数）だけ出力し、改行を出力し、先頭から1byte（または1文字）シフトした位置から同じように出力し、改行を出力し、再びシフトし――ということをファイル終端まで繰り返すコンソールアプリだ。例えばこんな感じ。 $ echo -n abcd | hcasl -n 1 a b c d $ echo -n abcd

id:eel3:20150622:1434981139 の続きというかやり直しというか。 使用したソースファイルの内容や、ビルド時のコマンドなどについては、前回のエントリを参照してほしい。 前回の落穂拾い (1)：Go言語で動的リンク Go言語は、本家プロジェクトのコンパイラで普通にビルドすると、静的リンクの実行ファイルが生成される。 # go version go1.4.2 linux/386 go build hello.go mv hello hello_bin/hello_go $ ldd hello_go 動的実行ファイルではありません $ _オプション -ldflags を使ってリンカにオプションを設定することで、動的リンクの実行ファイルを生成できるようだ。 # go version go1.4.2 linux/386 go build -ldflags '-linkmode

ゴールデンウィークなので折角だから借りてきた。 プログラム書法 第2版 作者: Brian W.Kernighan,P.J.Plauger,木村泉出版社/メーカー: 共立出版発売日: 1982/06/20メディア: 単行本購入: 1人 クリック: 166回この商品を含むブログ (31件) を見る──というのは嘘。実際の所は、図書館のカードを更新しに行ったついでに気の迷いで借りてしまっただけ。 以前も借りたことがあるのだが、『プログラム書法 第2版』は良い本ではあるけどちょっと古すぎる。サンプルコードがFortran*1やPL/I*2である時点でこの本の良さが大幅に削がれている。21世紀のプログラマには色々と厳しい。 まあ今や後継たる『プログラミング作法』がある訳で、普通はそちらを推奨するのだが。 ただ何というか、コメントの書き方に関する記述は『プログラム書法』の方が分かりやすいと思うのだ。

Cで書いたアプリケーションにLuaを組み込む機会があったので、メモを残しておく。具体的な組み込み方（LuaのC APIの呼び方など）はネットに出回っているし、本も何冊か出版されているので、それ以外について書き記そうと思う。 タイトル名の通り、設定ファイルとして使うために組み込んだので、その方面の内容が中心だ。ちなみに組み込み先はUnixアプリで、よくあるxxx.conf的な設定ファイルの代替に使用した。なので、設定ファイル機能は読み込み専用だ。変更した設定を上書き保存する機能はない。 最近ではTOMLも悪くない選択かもしれないが、仕様・実装ともにまだ枯れていないようだからなあ。 設定ファイルにLuaを使うメリット たかだか設定ファイルごときに言語処理系を組み込むだなんて過剰な気がしないでもないが（だって別に、Luaで書いた関数をアプリから実行するわけでもないのだし……）、しかしそれなりに利

タイトルに若干偽りあり。C言語・Common Lisp（ECLとMKCL）・OCamlも含んでいる。 一応、組み込みっぽい業界にいる人として、C言語の次のシステム・プログラミング向けの言語は興味の対象だ。 もちろん、今すぐ急に別の言語に移行するような事態は、可能性として低いだろう。アセンブラ全盛期から長い時間をかけてC言語や「C言語とインライン・アセンブラの混合」に変化したように、（今回も同じ程度の期間を経るか否か定かではないものの）それなりに時間がかかると思っている。 ついでにいうなら、今でもアセンブラを用いる部分が残っているのと同様に、次のシステム・プログラミング言語が主流になったらC言語が絶滅するとは思っていない。明らかにハードウェアやOSのシステムコールに近い階層では、C言語が生き残るだろう。一方で、組み込みシステムの上位階層側では、現在でもC言語からC++への移行が見られるように

2013年の年頭にあたり、プログラマらしくFizzBuzzをば。 Windows PowerShellは強力な反面癖もある言語で*1、基礎文法に関しても強力だけど普段使うことが少ない機能がある。 最近PowerShellでツールを作っていて、そんな「強力で面白いけど色々あって使わない」という（よくあるPowerShellのコードからすると幾分と変態的な）機能にようやく気づいたので、記念にFizzBuzzしておこうと思う。 ノーマルなFizzBuzzを見たいのなら、以前のエントリ id:eel3:20100704:1278237090 をどうぞ。 なお本エントリは「変態的」という言葉を冠しているとはいえ所詮は「変態度：低」の入門編なので、誰かが「変態度：高」な内容を書いてくれることを期待している。 switchでループ：その1 他言語経験者が気づきにくい機能No.1じゃないかと思う。 swi

こんな記事がアップされていた。 C言語のバグ回避をするための習慣 - Qiita 「へぇ」「ふーん」という感じに眺めていた訳だが。 自称職業Cプログラマ*1の自分の場合はどうだろうか？　実は、保守的ながらも意外とツールに頼っている。機械に任せられるところは任せてしまい、もっと集中すべき所に資源を投資しましょうや。 というわけで、組み込み系のクロスプラットフォームなライブラリ屋の習慣の一例： C/C++コンパイラの警告 ≒ 他の言語のコンパイルエラー／実行時エラー はいここテストに出まーす。 C/C++コンパイラが吐き出す警告は、特段の理由がない限り見敵必殺ですな。理由を調べて、しかるべき適切な処置をとるのが、よく訓練されたCプログラマだと思っている。 他の言語ではコンパイルできなさそうなケースでも、CやC++では警告で済んでしまうことは多い。ホント、Cプログラミングは地獄だぜ！ とりあえず

これは備忘録。 色々あって、まだ具体的なモノを何も作ってもないのにシェルスクリプトのパフォーマンス絡みでネタを収集してしまったので、ひとまずまとめてみた。 shellshock（bashのアレ）があったばかりなので、ちっとばかり微妙かも。 計測してボトルネックを探す まずは何よりも計測すること。time(1)を活用すべし。 データ量が多いと問題が表面化するのが定番のパターンなので、ワンライナー等でさくっとテストデータを作成して実験すると吉。 ループ構文よりもテキストフィルタを使う 一般的には、ループ構文を使うよりも、パイプでテキストフィルタに連結して処理した方が高速だ。 # NG seq 1 1000000 | while read i; do echo "$i"; done # NG # while readほどではないが遅い # （bashでは動いたが、dashやbusyboxのshで

数ヶ月前、Qiitaにこんな投稿があったようだ。 [教えて]Go言語:なぜインターフェイスはポインタにできない? - Qiita 内容は元記事を読んでもらうとして、ちょっとスッキリしない点があった。具体的には： ありがとうございます! ・インターフェイスはポインタにすることができるが、 ・インターフェイスのポインタにはインターフェイスとしての機能がない という理解になりました。 Cプログラマ的には、「ポインタと実体は別物」という意識があるのと同時に、「デリファレンス」の存在も心得ている。なので、「インターフェイスのポインタにはインターフェイスとしての機能がない、という理解になりました」と言われても困るというか、「おまえは何を言っているんだ」と返したくなる。 ポインタと実体は別物だ。つまり、インターフェイスのポインタとインターフェイスそのもの（実体）は別物だ。別物だから、ポインタに実体が持つ

ここ10ヶ月ぐらいだろうか、偶にWindows 7のシャットダウンに失敗することがある。次回起動時に「Windows は予期しないシャットダウンから回復しました」というダイアログが表示される。「問題の詳細の表示」で詳細情報を見てみると、「問題イベント名 BlueScreen」「BCCode 9f」となっている。 「BCCode 9f」はDRIVER_POWER_STATE_FAILUREを意味する。Windowsカーネルの電源絡みの状態遷移（スタンバイ ・休止への移行や復帰、シャットダウンなど）にデバイスドライバが正しく対応できていない際に発生するようだ*1。 乱暴に言ってしまえば「何かのデバイスないしデバイスドライバが悪い！」ということだ。ということなのだが、このダイアログは普通の人にとって何を言っているのか分からない代物なので、単純に「Windowsが悪い！」と結論付けてしまいそうな気

一応職業プログラマなのだけど──いや、職業プログラマだからこそか？　なぜか有線でLAN環境を構築するための機材の選定をすることになった。スモールオフィスぐらいの、こぢんまりした規模だ。 無線LANからの移行だ。ここしばらく無線LANの調子が悪く、近所の別のアクセスポイントでも調子が悪いので、周辺環境の変化で悪化したのではないかと判断した結果だ。本当の原因は異なるのかもしれないが、あれこれ調べるよりも有線にしてしまうほうが早い。 有線にするにあたり、ギガビット環境で構築しようということになったのだが、スイッチングハブやLANケーブルの選定基準となる知識が全くなかった。いや、自宅はギガビット環境なのだけど、単に1000BASE-Tに対応したLANポートが付いている有線ブロードバンドルータを使っているだけなので。 そんな訳で先達に意見を求めたりネットで調べたりしたので、メモを残しておく。 ギガビ

本エントリ名のような質問にたいする回答をよく忘れてしまうので、ここにメモしておく。 仮引数にvoidを書く／書かないについては、C言語とC++で言語仕様での扱いが異なる。C言語の場合は、関数の宣言か定義かによっても差異がある。 この違いを表にするとこんな感じ。 言語 宣言／定義 f(void) f() C言語 関数宣言 引数なし（ANSI Cのプロトタイプ宣言） 任意の個数の引数（K&Rの頃の伝統的な宣言） C言語 関数定義 引数なし（ANSI Cの関数定義） 引数なし（K&Rの頃の伝統的な関数定義） C++ 関数宣言 引数なし（プロトタイプ宣言） 引数なし（プロトタイプ宣言） C++ 関数定義 引数なし（関数定義） 引数なし（関数定義） C言語のみを使う場合 ANSI Cでコードを書いているならば、引数をとらない関数の仮引数にvoidを書くべきだ。 関数の宣言・定義ともに、仮引数にvoi

（※2016-08-28：この記事の内容は古いので id:eel3:20160828:1472388242 を参照のこと） id:eel3:20140308:1394260858 の続きかもしれない。 Node.jsにはWindows用のインストーラが存在する（しかも公式に配布されている）というのに、なぜ手動でインストールするのか？　そこに正式な手動インストール方法があるからだ。 公式サイトのダウンロード一覧から、Windows Binary（node.exe）を入手する。今回はv0.10.26。 ダウンロード一覧のページのOther releasesというリンク経由でnpmのアーカイブ一覧にたどり着くので、そのからnpmを取得する。今回はnpm-1.4.3.zip。 Node.jsとnpmを配置するフォルダを作成する。例えば「C:\node」とか。 前項のフォルダ直下にnode.exeを

会社の新人教育のような場では、課題のソースコードを提出するとまず「コメントを書け」と指摘されて、次に提出すると今度は「コメント多すぎ」と指摘されたりする。というか自分が教育担当だと、こういう新人からしたら理不尽に思われるだろう発言をしてしまう気がする（これはひとえに「何をどうコメントするべきか？　逆に、何をどうコメントするべきでないのか？」という点を適切に指導できていないだけ。大いに反省するところだ）。 ソースコード中のコメントの適切な量はどの程度なのだろうか？　言い換えれば、コメントは多いほうがよいのだろうか、それとも少ないほうがよいのだろうか？ 難しい問いだ。私なら「両方」と答える。（少なくとも手続き型の系譜のプログラミング言語を使用しているのなら）コメントは多めに書くべきだし、一方で減らすべき対象でもある。 ネットでは「コメントは少なくするべき」的な主張が目立っている印象がある。個人

http://eetimes.jp/ee/articles/1311/11/news072.html 推測というよりも半ば妄想混じりであるという点を先に述べておく。そもそも私は車載関連の開発自体との縁が全くない。 ただ、車載ではないがミッションクリティカルな組み込み開発（下手すると死人がでてしまう分野）の人から本件のヒントとなりそうな話を昔聞いたので、うろ覚えだが書いておく。 その前に、記事からは不明な点： 1万1000個のグローバル変数は、本当にグローバルなグローバル変数だったのか？ 要するにファイルスコープ変数（static修飾子を付けたグローバル変数）は1万1000個の中に含まれているのか、いないのか？ 仮に含まれているとしたら、その割合は？ 仮に含まれていないとしたら、ではstatic修飾子付きの変数は何個あったのか？ 仮に全てstatic修飾子が付いていないグローバル変数だったと

PowerShell 1.0の頃から例外処理用にtrap文が用意されていて、これがまた興味深い。 trap文の元となったのは、おそらくBourne shellの系統のシェルに用意されている組み込みコマンドtrapだろう。『Windows PowerShellインアクション』1.2.1によれば、PowerShellの設計においてPOSIX shellの文法を研究したらしい。POSIX shellはksh（UNIX Korn shell）のサブセットであり、kshはBourne shellのスーパーセットだ。当然ながらtrapをサポートしている。 ただ元々trapはUnix環境との結びつきが深いコマンドで、異なるOSであるWindowsに導入するにあたり、その役目を変化させている。Unix環境のtrapはシグナルを捕捉し、PowerShellのtrapは例外を捕捉する。 シグナル Unix環境

test(1)を使ってあるファイルがシンボリックリンクか否か判定しようと思い、Linuxのjmanを見てみた。該当するオプションは-hと-Lのようだ。 -hと-L、どちらを使うべきかについてはjmanには書いてなかった。ということはどちらを使っても問題なさそうな気がするけど、かえってどちらを使おうか迷ってしまう。 同じ機能が割り当てられているオプションが2つ存在することには、何か歴史的経緯が絡んでいる気がする。多分、過去との互換性とか、そんなものだ。 ネットでSlackware 3.1（1996/07）のmanを見つけたのだけど、この頃は-Lの記述しかなく、-hは書かれていない。ちなみに、厳密にはGNU Shell Utilitiesのmanのようだ。 他の古いLinuxディストリビューションのmanも見てみた。Red Hat Linuxは7.3の頃まで-Lのみで、8.0以降で-hと-Lの

ものすごーく久しぶりに――具体的には6年ぶりぐらいに――偽アセンブラであるCASL IIを触ってみようと思い立ったのだけど、WindowsはともかくLinux上で使えそうなシミュレータがなかなか見当たらない。 「Linux CASL」等でググってもIPAのサイトで公開されているCASL IIシミュレータ（以下、JavaCASL2）しか引っかからない。Javaで実装されているので動くには動くけど*1、実際にLinux上で環境を構築して動かした云々のネタは見つからない。なのでドキュメント片手に自分で環境構築しようとしたら、付属のドキュメントもサンプルもイマイチで、一見して参考になるようで結構当てにならない*2。 そんなことがあったのでメモを残しておこうと思う。まあJavaCASL2をLinux上で使う人なんて基本的に物好き以外の何者でもないので、ある程度分かっている人向けの内容となっている。

何やら最近C言語のポインタが熱いらしいので、自称Cプログラマとして書き残しておこうと思う。 私はポインタについて余り苦労することなく使ってきた人で、というかむしろポインタが無いと困る。構造体を引数にとる関数の仮引数はポインタで、リストやツリー構造での参照もポインタで*1、関数ポインタと関数ポインタの配列のどちらも大好き、という程度にはポインタを使う人なので「ポインタ禁止」とか無理だと思う。*2 なので本エントリは「ある程度ポインタを使える人による『ポインタの難しさ』の考察」ということになる。 Cの文法のマズさによる混乱 C言語の宣言周りの文法の筋の悪さについては例えば『エキスパートCプログラミング』のchapter 3で触れられている。この筋の悪さ故に、慣れないとポインタの宣言に型修飾子（constとvolatile）を付ける時に迷うことになる（要は「『constなオブジェクト』を指し示す

MISRA C という失敗 (#2295472) | コーディング標準は役に立つのか | スラド 早期returnとMISRA-Cルール14.7は背反か否か． - Togetter MISRA-Cはそもそも、 どのルールを守り、どのルールから逸脱するのか検討し、決定する。 上記の決定内容とその理由（順守するルール、逸脱するルール、逸脱の理由と範囲など）についてドキュメント化する。 ――という工程を経る前提で作られているルール集なので、「使い物にならない制約」と感じるのなら逸脱して構わない（ただしプロジェクト内で議論したうえで、必要な部分はしっかりドキュメント化してね）のだけど、それは置いておいて。 付け加えるのなら、自分なら例えば「使用条件をドキュメント化した上で限定的にgotoを許可する*1」とかやるだろうけど、それも置いておいて。 MISRA-Cにて「関数の末尾以外の return 禁