はてなブックマークエンジニア、ディレクターを募集します - naoyaのはてなダイアリー
ご存じの方も多いとは思いますが、新はてなブックマークの開発を進めています。はてなブックマークをスクラッチから開発し直し、ユーザーインターフェイスや各種機能の見直しと更なる楽しさを追加してユーザーのみなさんにお届けするための企画/開発作業です。 詳しくは以下の記事などを参照ください。 はてなブックマークの作り直しについて - naoyaのはてなダイアリー 今夏に新はてなブックマーク登場--その進化と情熱 - CNET Japan 現在は、自分とデザイナ、インターフェイスエンジニアの3名で開発を進めています。5月の中ごろまではある程度規模のコードベースをまず作るために、自分が一人で開発を進めていましたが、先日から3名でチームを作って次の段階に入っています。各種ページのデザイン及びサイト設計を詰めるのと並行しながら、新しく搭載する機能やインターフェイスの検討などを行っています。昨日も夕方にオフィ
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
1業務9万8000円，超低価格のオーダーメイド・システム開発「ギョイゾー！」，スターロジックが開始
システムインテグレータのスターロジックは2008年4月28日，1業務あたり9万8000円でオーダーメイドによるシステム開発を請け負うサービスを開始した。名称は「ギョイゾー！（GyoiZo!）」。見積管理や会員管理といった業務が9万8000円でIT化できるという。 「ギョイゾー！」では9万8000円でシステム化する1つの業務を「インフォセット」と呼ぶ。インフォセットは請求書などの書類（帳票）と，それに関する作成・承認・修正・取り消し・削除などの機能からなる。またさまざまな検索条件でデータをCSVファイルとして出力でき，Excelなどで自由に分析，加工できる。 システムは，顧客との打合せから1週間前後で納品する。納入されたシステムに対しユーザーが納得しない場合は「利用開始から90日間であれば全額返金する」（スターロジック）という。 インフォセットを追加する場合，「インフォセットすくすく成長オプ
シネマコンプレックス「新宿バルト9」の驚嘆すべき大バカ最低システム - 檜山正幸のキマイラ飼育記 (はてなBlog)
驚いた。あきれた。なにがどうなったらこんなバカげたシステムができるのだろう？ 補足解説編もあります。 さらなる補足。 コメントをしたい方は、なるべくコレにも目を通してみてください。 連休・子連れで映画館へ 連休、安直に「映画でも」と、子供二人を連れて「新宿バルト9」にはじめて行きました。9つの映画館を集約した施設、なかなかリッパです。上映開始10分前に着いたのに、既に長蛇の列、結局25分も並ばされた。すごく混んでいた？ いやっ、さほどではなかったんですよ。長蛇の列の原因は、発券カウンターの処理能力が異常に低いためでした。 上映開始15分後に入れた -- ってことは 9つの映画館すべてのチケットを一箇所の総合カウンターで発売します。全席指定、完全入れ替え制です。僕らは結局、到着25分後／上映開始15分後に入れました。ここで少し考えれば、次のことがわかりますよね。 満席になればその回は入場でき
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
コードに入らずばコーダーを得ず : 404 Blog Not Found
2007年11月21日00:00 カテゴリArt コードに入らずばコーダーを得ず これを見て(38|0x26|046)な俺も書きたくなった。 36歳になって思う「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan プログラマ、SE、マネジメント、経営の一通りを経験してきて、その説の私なりの考えを書いてみたくなった。 久しぶりに「私」でなくて「俺」で書く。 36歳になって思う「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan俺に限って言えば・・・35歳定年説は本当だった。というより、プログラムを動かすことより、人を動かすことに魅力を感じてしまったのだから、ずっとプログラマだったらどう思うかというのは残念だがわからない。 俺は、実のところプログラムを動かすのと同じぐらいかそれ以上に人を動かすのも人に動かされるのも好きだ。 だから、わかる。 プロ
新生銀行の件のフォローアップ:江島健太郎 / Kenn's Clairvoyance - CNET Japan
前回の新生銀行のサイトの使い勝手についてのポストに思いのほか反応がありました。 はてなブックマークでも「新生の使いづらさは尋常じゃない」とか「こに書いてあること全部の10倍くらいダメ」とか「書いてもらえてスッキリした」みたいな反応が多くて、そういう声を引き出せたのは書いた甲斐があるなぁ。 それで、セキュリティに関する話だから噛みついてくる人もいるだろうと思っていたらやっぱりいて、カレーなる辛口Javaな転職日記で「全般として，いかにも素人っぽい批判に終始しているように思う」と書かれていたのを見つけたので読んでみたのだけど、そこに書かれていた反論は「もっとセキュリティを下げろなんて論外」という、予想通りのいわゆる一段階論理だったのですが、よく考えてみればそういう思考回路の髪のとんがった上司をどう説得するかというシチュエーションは現実問題としてあるわけで、そのためもう少しだけ深追いしてみること
はてな：日本のIT・WEB制作業の人材確保裏事情 - カレーなる辛口Javaな転職日記
http://q.hatena.ne.jp/1184913023 こっちは「こちら側」の話． 私はIT・WEB制作業に関する会社で人事をしております。 A:私も数年人事をしておりますから、面接時の受け答えや実績・履歴内容で判断しております。 まず人事の人間が技術者の面接をする．これがダメなIT企業の特徴です．*1 特に「面接時の受け答え」なんてのは，どーでもいい話です．履歴書もほとんど参考になりません．*2そんなものでしか判断できない人間を外して，現場の技術者に面接させましょう． なぜ、IT業界だけモラル低下がひどいのかよく理由がわかりません。 あんたみたいな『無能な』人事担当者がいるからでしょう． 一般的な制作料金（外注依頼費・給与）を計上しているつもりですし、(中略) 他の同業他社に聞くと、どこも同じような人材トラブルに見舞われているようです。 技術者が質・量共に，圧倒的に不足した結果
Rubyは遅いから使えるのです : やむにやまれず
2007年07月20日13:00 by 山崎泰宏 Rubyは遅いから使えるのです カテゴリRuby開発スタイル Tweet sparklegate Comment(1)Trackback(0) 「Ruby なんて遅くて使えないよねって言ってみる」を読んで： 逆でしょう。RubyやRailsは遅いから使えるんです。 論点を整えますが、設計者、主にプログラマから見て「使える」と表現しています。 経営やプロジェクトマネジメントの観点まで広げると、Railsを採用するということは端的に言えば、「開発フェーズを効率化して運用フェーズでコストとして被る」ということです。 ビジネスプランも加味した上でのトレードオフになります。 言語のパフォーマンスを重視してみたところで無駄 - 開発者はみんなフレームワークを欲しがる：文句無しにパフォーマンスが良いので、Cで全てを書くとどうなるかです。 設計の初期段階で
♪ バグは夜更け過ぎに仕様に変わるだろう : 小野和俊のブログ
トラックバック一覧 1. バグはいつか仕様に変わる？ [地方で活動するweb制作者の日々を綴るblog] 2007年07月18日 14:25 「バグは夜更け過ぎに仕様に変わるだろう」 というのは、IT屋さんの中では有名な格言らしいのですが（私は知りませんでしたが）、その全文版を公開したそうです。 業界の人なら受けること間違いなし。 そして、現実と照らし合わせてぞっとすることも間違いなし。 IT 業... 2. 2007年7月18日 1907年はこんな時代 [神戸の三代目] 2007年07月18日 20:04 またヤフー株が米国につられて下げてる・・。誰かアナリスト、ちゃんと指摘してよー。ネタ加藤一二三九段伝説 前も書いた気もするけど、加藤一二三が凄い（というか面白い）。 一芸に秀でている人はぶっ飛んでいる人が多 3. [研究室][雑記] [Gabari] 2007年07月18日 20:22
$ dropdb 人生 - あなたの一言がどのように広まるかをシミュレートしてくれる『うわさメーカー』
賃貸暮らしのわが家の地震対策【揺れから命を守る編】 以前のブログでも記載した、防災の優先順位に基づいて対策を進めています。まだ手をつけられていない部分もありますが、ある程度まとまってきたのでざっくりとご紹介していきます。 優先順位別に改善していっているため、今回は主に地震の揺れ対策がメインになります。…
Webアプリケーションを作る前に知るべき10の脆弱性 ― ＠IT
Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP（Open Web Application Security Project）は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ
まつもと直伝 プログラミングのオキテ---目次 - まつもと直伝 プログラミングのオキテ：ITpro
第0回 あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画（2005年4月号）として，Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか，なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と
Cocoa はじめの一歩
Cocoa はじめの一歩 はじめに MacOSXになってからプログラミング環境が無料で手に入るようになりました。学割でも数万円はするソフト（CodeWarriorなど）を苦労して買っていた昔とは隔世の感があります。 せっかくタダなんだからちょっとやってみよう！と興味を持たれる方は多いのではないかと思います。 現在Cocoaに関して優れた本がいくつか出版されていますが、どれもプログラミング、特にCに関して基礎的な知識が要求されます。ではまずはCを勉強してみよう、と思ってもWindowsをベースにした説明ばかりで（コードそのものは同じなのですが）完全な初心者には「Macではどうすれば良いの？」と意外に敷居が高いのが現状です。 ここでは「完全な0から」始めたい人向けに簡単なガイドを提供したいと思います。 なお一概にプログラミングといっても現在Macのデスクトップアプリケーショ
koyachiの日記 - Joshua Schachter(del.icio.us)による大規模アプリケーション構築の注意点
del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
笑わないプログラマ - 【軍曹が】携帯電話開発の現状【語る】
天才プログラマ（スーパークリエータ？）に認定されました - higepon blog