おっと、タイトルだけ見て、先週から話題になっているはてなブックマークボタンのトラッキング問題の話かと思われたかもしれないが、本文でははてなブックマークの問題はほとんど扱わない。また、この問題について未だご存じない方は、ARTIFACT@ハテナ系のエントリの後半にあるこれまでの流れを辿ると分かりやすいだろう（ワタシ自身の認知にも近い）。 はてなが新サービスとしてはてなブログをリリースして4ヶ月以上経つ。当初は招待制だったが、昨年末にオープンベータに移行して現在にいたっている。 ワタシもリリース時に招待されたので少し触ってみたが、機能が何から何まで足らないことにびっくりしたものである。そして、はてなは「アレ」をやらかしたのではないかという疑念が頭をよぎったが、まさかと思う気持ちと、短時間触っただけの印象で間違った批判をしてはいけないという自制、何よりそのあたりはじきに解決するのだろうという楽観
Programingに関するmasutaka26のブックマーク (184)
-
masutaka26 2012/03/12
-
ぷっちん日記(2012-03-05)
■ 呼び出し側から書く Rubyを使うようになってからのような気がするが、私は日頃、コードを「呼び出し側から書く」ようにしている。とても役に立つ手法だと思うので、ここで紹介したい。 例えば、勤務表から総役務時間を得たいとする。 このとき「ええと、勤務表である MonthlyWork クラスのインスタンスには日ごとに DailyWork があって、それらのうち実役務時間と有給休暇を足して... 」といったことを考えたりは *しない*。 「どうやってその機能を実現するか」を最初は考えないようにする。「本当にその機能を実現できるだろうか、不安だ」というような感情が襲ってくることもあるだろう（特に初心者には）。しかし、大概のことは最終的には実現できるし、もし本当に実現できない問題があったとすればそれは個人のせいではない。 「どうやってその機能を実現するか」を考え始める代わりに、私はまだ存在しないそ
-
JavaScriptでオブジェクト志向的に、MVC的に書く - 憧れ駆動開発
完全に手続き的に書くというより、すこしMVCというかMVVC的な構造に切り分けてかいたらいいのではという内容。チラ裏に移動させた
-
Joel on Software - 射撃しつつ前進
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ
-
Google のコードも最初は大学レベルだった - 武蔵野日記
3月は論文の〆切が2-3個あるので、それを避けるように引っ越し日程を詰めているのだが、なかなか難しい。もはや数万円高くなるくらいは諦めている (論文の〆切間際は1日でも時間を大切にしたいので……)。 [twitter:@hillbig] くんが以前紹介していた「IN THE PLEX グーグル ネット覇者の真実」 グーグル ネット覇者の真実 追われる立場から追う立場へ 作者: スティーブン・レヴィ,仲達志,池村千秋出版社/メーカー: CCCメディアハウス発売日: 2011/12/16メディア: 単行本購入: 8人 クリック: 447回この商品を含むブログ (55件) を見るを登美ケ丘イオン (NAIST から最寄りのイオン) で先日発見し (ちなみに高の原のイオンの書店にも何冊か入荷している)、少しずつ読んでいたのをようやく読了。ものすごいボリューム……。しかし少なくとも情報系の方は必読。
-
-
Twitter に入った
Twitter に join してから、今日でちょうど1か月になる。 入る前は、もうだいぶ人数が増えてしまってるし、大きい会社っぽくなってないか心配してたんだけど、ぜんぜんそんなことないみたい。いい感じの居心地で、毎日が楽しい。 いまいるチームのエンジニアはみんなかなり優秀で、学ぶことが多い。 一番すごいと思ったのは、成果を出すための思い切りの良さ。限られた時間の中で目的を達成するために、多少デメリットがあっても、最短と思える方法を取ってくる。少々コードが汚くても、パフォーマンスが悪くても、目的を達成できればいい。あとで時間が取れたときに、ゆっくり直していけばいいという考え方のようだ。 1日で80%動くものをリリースしたほうが、1週間で100%動くものをリリースするより価値が大きいというわけだ。 ぼくは、なんでもわりと丁寧に作ってしまうほうなので、目的に応じて手の抜き方を工夫していくと、も
-
Google Chrome版Firebug：デベロッパーツール取扱説明書 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
-
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
-
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
-
技術/UNIX/GLOBAL(gtags,htags) - Glamenv-Septzen.net
id: 502 所有者: msakamoto-sf 作成日: 2009-11-25 13:36:46 カテゴリ: Linux UNIX プログラミング [ Prev ] [ Next ] [ 技術 ] ソースコードタグシステムの GNU GLOBAL メモ。日本人が作ったGNUツール。 http://www.gnu.org/software/global/ http://www.tamacom.com/global-j.html http://www.gnu.org/software/global/manual/global.html ソースコードを解析するのに便利。特に、htagsコマンドでHTML化してくれる機能が特徴的。 使い方メモ 結構有名で、ブログとかでもまとめてる人がいるので適当に検索すれば大体分かる。 まずTAGデータを作成するには、ソースコードツリーのTOPにcdして、 g
-
New community features for Google Chat and an update on Currents
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
-
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
-
コードリーディングについて | ありえるえりあ
コードリーディングについて アリエルネットワークCTO 井上誠一郎 自己紹介 書籍 「P2P教科書」 「パーフェクトJava」 「サーバサイドJavaScript入門」 「パーフェクトJavaScript」 今回の講義 心構えや経験談が中心 抽象論になりすぎないように実践可能な「トライ」ページ 次回講義の予告 3月1日の予定 「Webアプリのアーキテクチャの歴史と進化」 専門用語多め 反応を比較して今後の講義の参考にします コードリーディング(1) 現場で重要なスキル 既存コードベースがある場合、書くコード行数は驚くほど少ない 学習と実務でのギャップ サンプルコードは短い コードリーディング(2) 既存コードを理解できないと デバッグできない 新機能の追加ができない 既存コードと同じコードを書いてしまう(無知ゆえのコピーコード) => 更に読みづらくなる悪循環 理解できないコードは悪 多少
-
クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ
最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので
-
dankogaiさんへの返信 : 小野和俊のブログ
昨日、「メンテナビリティの高いソースコードを目指して」というエントリを書いたところ、dankogaiさんから、「コードも見せていないお前にコードを語る資格はない」と怒られてしまったので返信エントリ。 実はブログを初めて1,2年くらいの頃はコードを含むエントリをそこそこ書いてたのですが、プログラマーでない知人から「何の話か全然わからなかった」と言われ、またdankogaiさんも指摘している通り、「コードについて書く方がコードを書くより読まれる現実」があり、コードを含むエントリはJava Programming Tipsという別のブログに移した経緯があります。 ではどこに力を入れているかというと、私が一番力を入れいてるのはDataSpiderという商用ソフトウェアの設計と実装ですが、これはアプレッソの50人の社員を10年間支えてきてくれているソフトウェアなので「はい、どうぞ」とソースコードをお
-
コンテキストスイッチ力
最近、社内で関わるプロジェクトが移り、当然と言えば当然だが生産性が低下している。ついでに、長いビルドの暇な時間に、プログラマの生産性ってなんだろうな、ってなことをぼんやり考えたりしている。 スーパーエンジニアは凡百なエンジニアの数十倍とか数百倍という生産性があるという。数十倍かはわからないけど確かにものすごく生産性の高いエンジニアというのはいる。いるのだけど、何故彼らは生産性が高いのか。っていうか、そもそも生産性、ってなんだろう。 一般的にプログラマの生産性というとコーディングスキルだと思われている気がする。だけど、それだけなんだろうか。そりゃ優れたコードを書くのは才能だし、スピードも才能で、ぼくにはそんなものはない。ただ、言語も開発環境も大同小異なプロジェクトのメンバー同士でも、かなり生産性には差がある。この差がコーディング能力だけでつくとはとても思えない。 高林さんの文章で、プログラマ
-
algorithm - Patricia Trie (Radix Trie) を JavaScript で : 404 Blog Not Found
2012年01月21日21:45 カテゴリTipsLightweight Languages algorithm - Patricia Trie (Radix Trie) を JavaScript で スマホ手袋 5本指全てタッチできる smarttouch 5105 ミドリ安全 寒いのでこれをしたまま書きました。 dankogai/js-trie-patricia - GitHub 404 Blog Not Found:Algorithm - 連想配列の実装としてのハッシュはオワコン? Trieが連想配列の代わりになるというのを体でも納得しておきたかったので。 はじめてのTrie というわけで早速作ってみましょう。あっけにとられるほど簡単です。ここではObject、つまり連想配列で分岐点を実現するというある意味本末転倒なことをしていますが、JSならばしかたがない。 var Trie =
-
コードを書けることで僕は本当に救われている - ihara2525's blog
普段僕が仕事でコードを書くことはほとんどありません。 コードを書くことでチームや組織に貢献したい、という思いは常にあります。 同時に、僕はそうすることで自分の価値を一番出せるんだろうか、という思いもあって、やっぱりこっちが強いので、一年ほど前に僕は基本的にマネジメントに徹することにしました。 それでもたまにコードを書きたくなったりしますが、自分が中途半端に参加すると、結局他の人の動きを止めてしまったりすることになるので、やらない方がよっぽど良いです。 「いや、採用とか組織作りとかやめて、本気でやったら俺の方が絶対に書ける！」みたいなのもなくて、集中してやってもたいした結果にならないでしょう。逆に、そうなっちゃうようだったら自分よりも優秀な人を採用できてない、自分の仕事をできてないってことです。 なので、最新の技術への理解や、素晴らしいコードを書くことに関して、僕は確実に、簡単に、僕の周りの
-
naoyaの寿司ブログ
http://d.hatena.ne.jp/tictac/20120110/p1 を読んで。本論とは少し外れちゃうんだけど うまくやる学生はそういう困難にぶつかったとき、自分の力不足と馬鹿さ加減に滅入る気持ちと闘い、山のふもとで小さな歩みを始めます。彼らは、プライドに傷がつくことは、山頂からの景色を眺めるためであれば取るに足らないということを知っているのです。彼らは、自分が力不足であると分かっているので助けを求めます。 このくだりはわかるような気がする。ソフトウェアの開発をやっていると、ときおり新しい言語とか、新しいプラットフォームにチャレンジしようということがある。iPhoneアプリを作りたい、とか、たまには毛色の違う言語を触ってみよう、とか。なんやかんやでもう10年以上、プログラミングはしているので、そういう新しいものを学ぼうと思ったときに、自分の能力を過信してか、いきなりそこそこ質実
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました