サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
「プレゼンテーションZen」や「Objective-C プログラミング」など、英国ピアソングループの技術書を国内で出版していたピアソン桐原は、ピアソングループから離脱し8月1日付けで「桐原書店」として再スタートを切ることを発表しています。 桐原書店としての再出発に伴い技術書の扱いが終了するため、これまでに出版された技術書は在庫限りになることが公式ツイートで明らかにされています。下記は「ピアソン桐原が版元になっている、主に翻訳ものの技術書たちがどうなるのか。」という質問に対する桐原書店公式アカウントの返答ツイートです。 @sobahhi ご心配をおかけして大変申し訳ございません。今後は、学習参考書と語学書に専心していくことになりますので，技術書は基本的にお取扱いがなくなってしまいます。書店さんの在庫限りとなりますので、お早目にご入手くださいますようお願いいたします。 — 桐原書店 (@Kir
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です -はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。はてなグループに投稿された日記データのエクスポートについて -はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記はてなグループ日記のエクスポートデータは2020年2月28
コードは綺麗だけど儲からないプロジェクトと、 コードは糞汚いけど儲かるプロジェクトのどっちがいいですか？ もちろん、コードは綺麗で儲かるプロジェクトがいいのは理想ですが、今回は、この2つです。 コードは糞汚いけど儲かるプロジェクトの場合、次期バージョンとかの予算を確保することができます。 そこで、汚い部分を捨てて書きなおすことだって出来ます。 コードは綺麗だけど儲からないプロジェクトは、次のバージョンの改修費用もでずにゴミ箱に送られる運命です。プロジェクト解散、メンバーは散り散りです。フリーソフトの場合は、儲かるをユーザに使ってもらえるソフトとか支持されるソフト、ゲームの場合は、儲かるを面白いゲーム、支持されるゲームとかと適当に読み替えてください。 コードは綺麗に越したことはないです。 だけど、プロジェクトとして成立しないことには意味がありません。 コードは綺麗だけど、誰も遊んでくれ
コードクローンと品質について話題になっている。元ネタはこちら。 ソースコードの品質についても、みずほ証券は問題を指摘している。今回のバグがあったプログラム全体について、「ソースコードの著しい重複が見られるなど、エラーの潜在する率が極めて高い作り方をされており、品質が極めて低い」と主張。これに対して東証は「コードクローン（記述の重複）を含むプログラムは、含まないプログラムと比較して信頼性が高いことが定量的な研究で裏付けられている」と反論した。 ［論点3］どんな開発手法を適用すべきか | 日経 xTECH（クロステック） この「コードクローンを含むプログラムのほうが信頼性が高い」というのはどこからきた話題なのかという話。 僕が昔読んだ論文で似たような話があったなと思って探してみた。 コードクローンに基づくレガシーソフトウェアの品質の分析(PDF)本論文では，20年以上前に開発され，拡張COB
概要 1ヶ月くらい一緒にお仕事している外国人プログラマさんを観察した記録です。 スペック 性別: 男性仕事内容: うちの会社のプログラマは、ざっくり JS 等のフロントエンドと、Java 等のバックエンドエンジニアにわかれているのですが、彼はどちらもやっているようです。 好きな食べ物: はちみつ たまに、くまさんのようにはちみつを舐めていました。 性格 彼はめんどくさがり屋です。 同僚のWindows ユーザの手伝いをしている時、 "C:¥Program Files¥..." みたいなパスを打ちながら、「めんどくさい。 ああ めんどくさい」 と 100回くらいつぶやいていました。 (普段の彼の環境はmac なので /usr/local/bin) パスワードを覚えるのもめんどくさいので 1Password で管理しているようです。PC スペック マシン:Macbook Pro メ
最近話題の エンジニアよ、ゼネラリストなんて目指すな！―VASILY 金山裕樹のキャリア論（http://japan.internet.com/busnews/20121130/3.html）を見て・・・ コードを書くことが目的化しちゃってる人も多いので全否定するつもりはないけど、コードが汚くても「アイツがいれば勝てる」と思わせる人間を素人判断で雇うことが如何に危険かプログラマ視点でまとめてみる。以下何度も見てきた典型的な失敗パターン、設計と実装が完全に分業化されてる分野は知らないけどWeb業界などそうでない所のお話。 手抜きプログラマは人を騙す非エンジニアを騙して手抜きするのは簡単。余程のヘタレでない限り手抜きをしても絶対にばれない。コードにコメントがなくてもモジュール化されてなくてもコピペ満載でもマジックナンバーだらけでも動いてさえいればユーザーは気にしない。 手抜きプログラマの評価は
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
最近、会社でリーダブルコードを輪読したり、Fukuoka.rb で EloquentRuby を読んだりしていて、メソッドや変数名の長さやコメントについての議論を読む機会があった。 昨日、たまたま 37signals のブログを読んでいたら、Rails の作者である David Heinemeier Hansson もこのトピックについて書いていた。 自分は WEB+DB PRESS で ukstudio さんの書いた RSpec についての記事を読んで感化されて以来、ソースコード中のコメントはすべて悪で、はっきりしたメソッド名、変数名を使えばコメントはいらないという考え方を持っている。DHH もそのような考え方のようだ。 Clarity over brevity in variable and method names – Signal v. Noise Many programmer
2006年04月30日03:46 カテゴリOpen Source タブのスペース化はタブ幅よりも重要である あえて断言します。君たちは半分しかわかっていないと。 Charsbar::Note - タブとスペースの話 あえて断言しときます。こんなモンはバッドノウハウなんであって、ベストプラクティスでもなんでもない、と。 最速インターフェース研究会 :: タブとスペースと萌ディタの話なんかそもそもタブを使わずにスペース4で統一せよってのはフォントサイズをピクセル単位で指定したがるデザイナの言い分みたいで気に食わない。君たちは、patchのことをきれいさぱーり忘れている。 人のコードを直したり、人にコードを直してもらったりしなくてもいいというのであれば、君たちのいい分ももっともだ。しかし、人とコードをやりとりする時にpatchをやりとりする場合、tabは頭が痛い以外の何者でもない。 以下に二つの
最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので
はじめに こんにちは、動画配信界の情弱です。年始からStackOverflow眺めてたら超絶便利な質問に神回答がされてたので忘れないうちにメモっておく。2012年どっかで役に立てばいいですね。 参考 オリジナルはこちら。ここではコメントにパラパラと載ってたので、まずは直近1ページ目だけにあったものを1個のリストにまとめてみた。ほぼGeorge Stocker氏による回答を載せただけだけど。あとちょっとだけ自分で和訳とか加えたので、知っているものがあればコメントに載せて下さい。追加します。まだDとかFactorとか載ってないし、Pythonも全然足りないし。API Only - Stack Exchange もしかするとバージョンが古かったりするものもあるかも知れませんが、それもコメントで教えてもらえるとその旨追記します。 他にも過去に挙がったもののリンク ReadWriteWebのプログ
条件分岐が頭に入ってこない体質なので、プログラミングは挫折してはや二十年。 年明けには、PT2録画物をh.264化するスクリプトは書きました。 ファイル名リストから加工して、シーケンシャル処理です。削除は半手作業でやります。 音声多重とかで、エンコード失敗がおきるんだけど、エラーコードハンドリングとか たぶん、おれはバグを生み出すだけだろうから、自動化は断念しています orz あと、r8168のドライバーのmake,make installはしました。 Core2Duoからi5に移行する際に、SSD差し替えで普通に動いていたんだけど バンダイチャンネルでずっとSEED見てたら17話あたりから、NICが不調になった。 週に1,2度ペースでNICらしいトラブルがあったから、遅ればせながら調べたら r8111はr8168ドライバーで動かすべきなのに 誤認識でr8169ドライバーで動いていることが
@shibataismさんが、日経Bizアカデミーに「日本のエンジニアはシリコンバレーで通用するのか？」という記事を書いている。 「僕は文系だけど、エンジニアとして一流だ」と自己主張する人がいますが、採用側から見て実際にそうであることは稀です。シリコンバレーの企業では、採用面接の際に「 ○○アルゴリズムを書いてみてください」といったように、具体的かつ実践的な課題が出されます。こうした面接で、文系の人は（そもそも大学できちんと勉強したことがないので）適切な回答をするのが難しい場合が多いのです。 とあるのだが、アメリカの大学で数学を勉強し、プログラミングは独習したソフトウェアエンジニアとして1、少し補足してみたいと思う。 「文系」だからといって諦める必要はない これはまあその人の経験によるのだろうけど、文系出身のエンジニアだからといって諦める必要はない。[平林さん](https://falla
10/27の夜に社内勉強会「開発環境勉強会：超エディタ論争」が開催されました。 9月に自称PHPer最強のVimerが入社し、社内のEmacserの心に火をつけたのが開催のきっかけだったようですが、当のVimerさんは体調不良で不参加と言う中、[twitter:@yattom]さんも見学に来られるとのことで強硬開催されました。 今回は、Vimer代表、Emacser代表、NetBeans代表がそれぞれネタを持ち寄って発表するとのことだったので、コンテンパンに叩きのめされるのを覚悟でネタで「秀丸代表」を務めさせていただきました(^_^;) エディタ論争と言うことでエディタの話題だけでしたが、開発環境はエディタだけでなく、OS、テスト環境、ブラウザ、ブラウザに入れるプラグイン、PC周りに置かれたガラケー、スマホなどの実機など、開発を効率化するために必要なあらゆる環境が今後の勉強会で議論されれば
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
