ついつい使ってしまうプログラミングの悪いテクニックは？ | スラド デベロッパー
プログラミングの際に、さまざまな理由でコーディングのルールを破ってしまうことがある。これらは誰もが「悪い」プログラミングテクニックであると認めるようなものだが、結果としてコードがクリーンになり、高速かつシンプルになることもある。InfoWorldの記事では、愛される悪いプログラミングテクニックを9つ選んでいる。 InfoWorldが選んだ悪いプログラミングテクニックは以下の通り。 gotoを使う 関数名だけで内容がわかるようにしてドキュメンテーションを避ける 1行に大量のコードを詰め込む 型宣言をしない 値の型を繰り返し変換する「ヨーヨーコード」 独自のデータ構造を書く ループの半ばでループを抜ける 短い変数名を使う 演算子や関数を再定義する プログラミング言語や環境によっては使用できないものもあるが、皆さんがよく使うものはあるだろうか。また、リストに追加するとしたらどのようなものがあるだ
「アセンブラ短歌」が書籍化される | スラド デベロッパー
ymitsu のタレこみによれば、31バイトでプログラムを書く「アセンブラ短歌」の解説書が発売されるそうだ(Mynavi Advanced Library特集ページ、 アセンブラ短歌)。 アセンブラ短歌とは、「五・七・五・七・七の三十一バイト(みそひとバイト)から成る 機械語コードでプログラムを書いてみるという近未来の文化的趣味」とのこと。近年、アセンブラ学習が見直されているが、遊び感覚でアセンブラを学習する方法として考え出されたものだという。31バイトの機械語コードが決められた位置で区切られるようにプログラミングし、韻を踏むために同じバイトパターンを決まった位置に埋め込むなどの技術を身に着けることで、バッファーオーバーランの脆弱性を攻撃するために送り込まれるシェルコードの解析や対策を考えるためにも役立つとのことだ。 書籍「31バイトでつくるアセンブラプログラミング ～アセンブラ短歌の世界
70～80年代のCOBOLシステムを支えたプログラマの引退が近づいているが、システムは動き続ける | スラド デベロッパー
1980年代には「COBOLは衰退するので、ほかのプログラミング言語に移行しなければならない」などと言われた。実際に1970～1990年代に書かれた細かなCOBOLプログラムのほとんどは新しいシステムと新しい技術に置き換えられている。しかし、銀行、保険会社、製造業、小売チェーン、医療機関といった大企業のミッションクリティカルなシステムは依然として大昔にCOBOLで書かれたコードによって運営されている。多くの企業はこれらのシステムを何度も入れ替えようとしたが、システムが全体が巨大で複雑な上、重要なビジネス・プロセスに統合されていること、また問題なく動いていることからこうした取り組みの多くは失敗した。 ITWORLDの記事によると、こうしたCOBOLで書かれたシステムを支えてきた団塊世代プログラマの引退が近づいているという（ITWORLD、本家/.）。 今は大学のプログラム講座などでは教えるこ
50歳になってもプログラミングを続ける理由 | スラド デベロッパー
ストーリー by hylom 2012年11月07日 6時00分 簡単にプログラミングできるデバイスが減っていくような気はするが 部門より 巷では「プログラマ35才定年説」などもあるが、Googleのソフトウェア開発者Vivek Haldar氏が、ブログで50歳、もしくは任意の年齢を超えてもプログラミングを続ける理由をリストアップしている。その理由とは、金銭的な収入がほしい、生活を便利にするための手段、創造する楽しさ、美しいコードを書くという自己表現の手段、知的な自己満足といったものだ（Vivek Haldar氏ブログ、programming in thetwenty-first century、本家/.）。 また、多変量解析ソフトウェア「SASシステム」などて知られる米国の億万長者の一人、SAS Institute社のCEO「James Goodnight」氏も56歳時点のインタビューで
2012年のシステム・ソフトウェア開発業者の倒産件数、過去最悪の水準で推移 | スラド デベロッパー
帝国データバンクが10日に発表した「システム・ソフトウェア開発業者の倒産動向調査」によると、2012年は4月までの倒産件数が88件。過去最悪だった2009年を上回る水準で推移しているとのこと(プレスリリース)。 レポートは2001年から2012年4月の間に発生したシステム・ソフトウェア開発を主業とする事業者の倒産件数や負債額を調査・分析したもので、パッケージソフトウェア業や情報処理サービス業、情報提供サービス業は含まない。4月時点で88件の倒産は、2009年(67件、年間206件)や2011年(74件、年間202件)を大きく上回る。また昨年までと異なり、業歴の長い事業者の倒産が多いという。倒産の原因としては、各所におけるシステム化の一巡や大手企業のシステム子会社設立、リーマン・ショックや東日本大震災などの影響で経費削減や事業計画の先送りが相次いだことなどを挙げている。 業界に身を置く/.J
第 20 回・国際分かりにくい C コードコンテスト、応募されたコードを公開 | スラド デベロッパー
5 年ぶりに開催された IOCCC (International Obfuscated C Code Contest、国際分かりにくい C のコードコンテスト) 参加者によるソースコードが公開されている。 受賞者はすでに発表されているが、どのコードも開いた瞬間に吹き出すレベルの難解さである。
長い関数名、変数名、どこまで許せる？ | スラド デベロッパー
最近久しぶりにWindows関連の案件に関わったのだが、ここ数年UNIX/Linuxばかりを触っていたので結構な違和感があった。特に気になったのが、関数名や変数名などの識別子が長くなる傾向がある点だ。たとえば「GetApplicationConfigurationString」とか、「SaveAllChangeSetToDatabase」とか、確かに分かりやすいのだがタイピングするのに指が絡まるわ！と思う識別子名が多々あった。 そもそもWindows APIには長い関数名、変数名が多く、IDEの補完機能によって長い識別子も入力しやすくなっている、という背景もあるのだろう。しかし、長い識別子名が多いと1行は78文字以内というポリシーを守るのがかなりきつい。長い識別子を許した方が分かりやすいかもしれないが、それでコードが見づらくなるのは個人的にはちょっと避けたいところである。 /.J読者でプロ
2011 年にシェアを最も伸ばしたプログラミング言語は Objective-C | スラド デベロッパー
TIOBE Software は、2011 年に最もシェアを伸ばしたプログラミング言語に贈られる「TIOBE Programming Language Award of 2011」を、Objective-C が受賞したことを発表した (TIOBE Index、SourceForge.jp Magazine の記事、本家 /. 記事より) 。 Objective-C は 2011 年 1 月時点と比べてシェアを 3.91 % 伸ばし、8 位から 5 位に上昇した。次にシェアを伸ばしたのは 2.55 % 増の C# で、6 位から 3 位に上昇。一方、大きくシェアを減らしたのは Python (-3.05 %、5 位→ 8 位) と PHP (-2.3 %、4 位→ 6 位)。シェア 1 位と 2 位は前年と変わらず Java と C だが、C のシェアが 1.15 % 増加したのに対して、J
JavaScript は何処へ行く? | スラド デベロッパー
JavaScript が今日最も重要なプログラミング言語の 1 つであることは、その善し悪しは別として疑いようもないだろう。各ブラウザは JavaScript エンジンのパフォーマンス向上に力を入れ、一種の競争のようなものが生まれている。そんなクライアントサイドウェブの共通言語ともいえる JavaScript にはこれからどんな未来がひらけているのだろうか? (InfoWorld の記事、本家 /. 記事より) 。 Google は「JavaScript の根本的な欠陥」を打開した新たな言語「Dart」を近々発表すると告知しており (/.J 記事) 、一方 Intel は並列処理機能を追加した「River Trail」で JavaScript の機能拡張を実現しようとしている (Publickey の記事) 。 一つ明らかなのは、JavaScript への需要は高まる一方であり、その結果こ
プログラマーの情熱を奪わない開発プロセスとは？ | スラド デベロッパー
テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。コードを100%レビューする。単体テストでのコードカバー率を70%にする。循環的複雑度を20以下に抑える。開発を始める前に顧客の要望を調整しておくなど。大量の「ベストプラクティス」は、それぞれ素晴らしいアイディアのように見える。しかし、ベストプラクティスをこなすことに追われる開発者には、革新的・創造的な作業をするための時間がどれぐらい残されるだろうか。 O'Reilly Radarの記事では、良いコードを確保するために取り入れるプロセスが多すぎると、開発者の情熱を奪ってしまうと主張している。 「素晴らしいコードを書くことのできるプログラマーから、プロセスが情熱を奪う。不満を抱くプログラマーが質の悪いコードを書き、良いコードを確保するために管理部門がプロセスを追加する、という悪循環に陥り、さらに士気が低下する」というこ
1 kB の JavaScript で何ができる ? | スラド デベロッパー
1 kB 以下の JavaScript デモを作るコンテスト「JS1K」が開催され、トップ 10 が発表された (本家 /. 記事より) 。 このコンテストのルールは「1 kB 以下の JavaScript でイケてるデモを作る」という至ってシンプルなもの。外部ファイルの使用は認められておらず、twitter で投稿できる 140 文字以内に収めた場合にはボーナスポイントがもらえるそうだ。 3 位のTetris with sound (音量注意) は操作はもちろん、題名の通りゲーム音楽までついている。1 位に輝いたのは「Legend Of The Bouncing Beholder」という横スクロールゲーム。 アクセス過多のためか残念ながらデモが開かないときもあるが、1 kB の可能性の大きさに改めて驚かされる。
「ウォーターフォール開発」、本当に日本でうまく行っているのか？ | スラド デベロッパー
「Continuous Delivery」というソフトウェア開発に関する書籍の著者、Jez Humble氏によりますと、多くの日本IT企業は大規模ソフトウェア開発プロジェクトでウォーターフォール（Waterfall）な開発手法を取っているのですが、この開発手法は世界中で多くの失敗を引き起こしているにも関わらず、日本ではなぜかうまく行っているそうです（Humble氏のブログ記事）。 /.J諸兄方の職場では、ウォーターフォール開発手法で本当にうまく行っていますか？ また、今使っている開発手法は何ですか？ これは、7月21日に行われたAgile Conference Tokyo 2010でのトークセッションで話題にされたそうで、参加者のレポートやTwitter実況などによると、Humble氏は日本の開発工程に「バグフィックス工程」がないことに驚いたらしい。頻繁なテストやコーディング段階での修正が
Kindle向けのアプリケーション開発キット発表 | スラド デベロッパー
2010年1月21日、AmazonからKindle向けアプリケーション開発キットの提供が発表された（Engadget Japaneseの記事、プレスリリース、特設サイト）。限定ベータの提供は来月からだが、これによって「Active Content」の開発が可能になる。 今年後半にはKindleストアでの配信に対応予定で、フリーウェア、有償、月ぎめサブスクリプションが選択できる。「印税」は最新の方針通り70％で、配信コストとして1MBあたり15セントが必要。アプリケーション容量上限は100MBで、10MB以上は内蔵の3G経由ではなく、PCでのダウンロード対応になる（後でUSB経由でKindleに転送）。フリーウェアの場合は1MB以下という条件がある。 また、いずれの場合でも、オンライン接続を要する場合は月あたり転送量が100KB以下の条件がある。VoIPは不可といった条件もある。開発例として
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
正規表現クロスワード、解ける？ | スラド デベロッパー
Perl、 25周年の誕生日を迎える | スラド デベロッパー