空いた時間にWEBシステム(ホームページだけでもいい)を(バイト感覚?で)受注する為の情報サイトを探しています。 PHP,Perl,MYSQL等は触れます。基本は、土、日、祝日を使って作りたいので、大規模なものより、掲示板やメールフォーム等のツール的なものがベストかなと考えています。もちろん時間をもらえれば、大規模なものもやりたいですが。 都合がいいようですが、この辺の「情報サイト」、もしくは、「やり方」をお教え下さい。
Webサービスは、コンピュータ同士を直接結んでリモートリソースにアクセスする方法の1つである。本稿では、SOAPやWS-*規格群など、Webサービスの基礎知識をまとめた。 物理的に離れたコンピュータのプログラム間で情報を交換できることは、今日の企業における標準的な要件の1つだ。そしてリモートリソースへの最も一般的なアクセス方法が、HTTPによるサーバからクライアントへのHTMLファイルの転送、要するにWebサイトである。こうした情報伝達のやり方が功を奏している理由は、シンプルで身近に利用できるテクノロジーと標準規格が使われている点にある。しかし、Webサイトには根本的な限界がある。Webページの情報を理解できるのは人間だけで、コンピュータにはそれができないことだ。 Webサービスは、コンピュータ同士を直接結んでリモートリソースにアクセスする方法の1つである。本稿では、SOAPのような基本的
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
Sun Microsystems Asia-PacificのスタッフエンジニアであるLee Chuk Munn氏によると、アプリケーションを書くことは本を執筆することに似ているという。 「私はさまざまなプログラミング言語を学んできた。しかし、どんな言語を使ってプログラムを書いているかは問題ではない。書く物語がよいものでなければいけないのだ」Lee氏はZDNet Asiaの電話インタビューでこう答える。ソフトウェアのプログラミングでは27年の経験を持つベテランのLee氏はSunのソフトウェア部門で働いており、社内の開発者やJavaやSolarisを使用している個人ソフトウェア開発者のネットワークを指導している。 彼はこう続ける。「プログラミングは解決策の一つの表現にすぎない。プログラミングの多くを構成するのは、問題を理解して認識し、助けを得ることだ。この考え方はすべてのプログラミング言語にお
最近,WebアプリケーションやWindowsソフトの取材で,“このソフトは担当者が一人で作っています”という事例に続けて遭遇する機会があった。フリーソフトや趣味のソフトではなく,会社が商品として提供し,不特定多数のユーザーが使っているアプリケーションを一人で作って,一人でメンテナンスしているという点に興味を覚えた。 先週都内で開催された開発者向けイベント「ITpro Challenge!」でも,ドワンゴの戀塚昭彦氏がニコニコ動画を一人で(しかも3日間で)作ったと語っていた(関連記事)。よく考えてみれば,ITpro Challenge!に登壇したようなハッカーとかアルファギークなどと呼ばれる優れた開発者でなくても,企業内で一人でソフトを作っているケースは思いのほか多いのではないだろうか。 アプリケーションの規模や内容,また開発者のスキルにもよるだろうが,おおむね一人で開発するほうが, ・低コ
はてなの京都オフィスの内装計画もいよいよ大詰めでプランがほぼ固まってきた。4月中旬には内装工事も終わってオフィスが正式オープンできることになった。本社移転発表後はたくさんの採用応募が来ており毎日書類選考に追われている状態だが、改めて今回のはてなの京都への本社移転に伴って、特にサービス開発周辺でこういう人を募集していますということを紹介したい。 サービスクリエイター、ウェブディレクター まずはサービスクリエイターおよびウェブディレクター。京都新本社の最大のミッションは、既存のはてなサービスを盛り上げながら、次なるヒットサービスを作ることだ。そのまとめ役をするのがクリエイター・ディレクターである。 今のところ両者の違いは、クリエイターは自分でプログラムも書いてプロトタイプや製品まで作ってしまう力がある人で、ディレクターはプログラムは書かないがデザインなどはでき、クリエイターとエンジニアの橋渡し
Webデザインとプログラミングの両方をこなすYasuhisaさん。「国際的な仕事をしたい」と米国に留学したが、そこで出会ったインターネットが人生を変えた。ロディアのメモからWebデザインを立ち上げる一方、PHPでプログラムも作成する。 「ひとりでつくるネットサービス」第9回目はWebデザイナーでありながら、サーバ設置型のRSSリーダーやポッドキャスティングのCMSを作るなど、プログラミングもこなすYasuhisaさんに話を聞いた。 「自分はプログラマーだ、自分はデザイナーだ、と思いこまずに、積極的にいろいろなモノを作ってほしい」。Yasuhisaさんはそう語る。畑違いだからといって「デザインをしない」「プログラミングをしない」では良いモノは作れないと信じている。デザインとプログラミングの両方をこなすYasuhisaさんが、そう思うようになった経緯はどんなものだろうか。 「国際的な仕事をした
The Linux Foundation Japan リナックスファウンデーション・ジャパン The Linux Foundationは、Linux® の普及、保護、標準化を推進する非営利のコンソーシアムです。 SI Forum いろいろなSIプロセスで使用できるOSSツールの調査 本調査は、2007年4月〜2008年2月の期間、本SI Forumに参加しているベンダ・SIerメンバーの協力によって行われました。 昨年度の「OSSミドルウェア/ツール調査」の作業を踏まえて、より多くのOSSドルウェアおよびツールをユーザー様、SIer様に使いやすい形で整理・公開すべく、今年度活動として、以下の3項目を活動目標としました。 参加各社がシステム構築(SI)に使用しているOSSツールを、各SIプロセス毎に整理する OSSツール情報をデータベース化し、必要なツールを簡単に検索できるよ
http://q.hatena.ne.jp/1184913023 こっちは「こちら側」の話. 私はIT・WEB制作業に関する会社で人事をしております。 A:私も数年人事をしておりますから、面接時の受け答えや実績・履歴内容で判断しております。 まず人事の人間が技術者の面接をする.これがダメなIT企業の特徴です.*1 特に「面接時の受け答え」なんてのは,どーでもいい話です.履歴書もほとんど参考になりません.*2そんなものでしか判断できない人間を外して,現場の技術者に面接させましょう. なぜ、IT業界だけモラル低下がひどいのかよく理由がわかりません。 あんたみたいな『無能な』人事担当者がいるからでしょう. 一般的な制作料金(外注依頼費・給与)を計上しているつもりですし、(中略) 他の同業他社に聞くと、どこも同じような人材トラブルに見舞われているようです。 技術者が質・量共に,圧倒的に不足した結果
「7 Signs Your Project Will Never Make it to Production」 という記事がありました。 フリーランスとして働いている著者が、プロダクトとして発表されるに至らないプロジェクトの特徴を述べています。 このような特徴を持つプロジェクトに参加しても、自身のポートフォリオに新しい製品を追加する事はできないそうです。 面白かったので要約してみました。 全てにおいて真であるとは思いませんが、何と無くありそうな話だと思いました。 1. クライアント側でUIモックアップを制作したことが無い クライアントは自分が何を制作したいのかを良くわかっていません。 2. クライアントは、ドキュメントではなく電話越しに内容を伝えようとする かなり危険な状態です。 何らかのドキュメンテーションが出来上がるまでは仕事を請けるべきではありません。 3. クライアントの個人的欲求
via del.icio.us/popular ソフトウェア開発プロセスに関するブログTyner Blainの記事Top ten tips for preventing innovationより、どうやったら革新的な発明をさせないことができるか、というアンチパターン集。 イノベーターを面接でうっかり採用してしまう 部下が指示通り動かずイノベーションを起こしてしまう そこそこの表彰や報酬ではなく、イノベーションに対価を与えてしまう うっかりイノベーションのための機会を作ってしまい、社員をそこへ殺到させてしまう といった失敗が多い、悩みのある企業に効く処方箋だ。 生活の安定を得ることを目標にしている人を雇う 無能な人を雇う。無能な人が雇えないときでも、一分野に特化した専門性の高い人を雇う 給与レベルは市場の75%以下におさえる。給与を上げるとイノベーターをひきつけてしまう イノベーションの達人
私は,2007年2月2日付の記者の眼「『使えない人間』などいない」で「Java初心者で構成されるチームがいかにプロジェクトを完遂したか,という事例」があり,その事例を取材したうえで,日経ソフトウエア2007年5月号のJava特集でレポートすると書いた。その号がいよいよ明日(3月24日),発売される。特集のルポ「Java初心者のチームが挑む基幹系刷新プロジェクト」という記事である。 具体的には,群馬県内の各JAやJA関連組織のIT共同利用施設であるJA群馬電算センターが提供しているシステムの事例だ。Javaをほとんど知らなかった4人のメンバー,JA群馬電算センター 経済情報部の片野富久氏,前原貴美子氏,大久保浩治氏,渋谷知央氏が,基幹系システムの刷新プロジェクトに先立つパイロット・プロジェクトを成功させた,というものである。 もっとも,取材を終えた今では,この事例を「『使えない人間』などいな
ドキュメントを作成しないユーザーは、失敗する:ユーザーサイド・プロジェクト推進ガイド(15)(1/2 ページ) システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか? コンピュータ・システム開発プロジェクトにおいて、ユーザーサイドではどのようなドキュメントが作成、準備されているのでしょうか? 対象業務の概要を個条書きしたもの、現状使われている伝票や帳票類、現行システムのソフトやハードの構成図、それに画面のハードコピー、もしくは完成図書一式を資料として用意すれば十分でしょうか? あとは打ち合わせの中でベンダへ口頭で伝えればよい──といえるでしょうか? 関係部署が1つか2つ程度で限られた業務だけを対象とする小規模なシステム、あるいは現行システムの単純な更新であれば、この程度の資料だけで間に
「実際のところ、建設業界と似たようなもんですから。」 ソフトウェア業界、とくにSI(ITサービス)業界で自嘲気味に語られることの多い台詞です。ゼネコンを頂点とする多重下請け構造や、労働集約型の現場を指して言うようですが、本当にそうなのでしょうか?私もこの業界長いですが、実際に建築業界に身をおいていた人が語ったのは聞いたことがありませんでした。そして、昨日まさに建設業界から見た双方の業界の比較について聞く機会があり、双方の違いと問題点を鋭く斬られていたので、他のメディア主催のセミナーの話で恐縮ですが紹介させてもらいます。 その話とは、日経ソリューションビジネスDAYの基調講演で大成建設CIO(社長室情報企画部長)の木内里美氏のお話。大成建設ではASTERIAもご利用いただいており、木内氏とも面識があるのですが、こういう切り口のお話を聞くのは初めてでした。講演の中で氏は、受託開発と建設業が似て
最近のシステム構築では仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成することも多いようだ。否定する気はないが、駆け出しのころはしっかり自分の手で仕様書を書いた方がいい。 前回は、SEを目指している皆さんに向けて、仕事に取り組む姿勢の観点からアドバイスを書いた。今回は、SEに求められるより具体的な知識やスキルの向上に役立つ話を書いてみたい。 SEとして必要な知識やスキルは非常に広範にわたる。経験を積み、上級SEになってくればより経営的な知識が求められるが、最初のころは、システム構築に必要な知識やスキルが特に重要になる。今回は、システム構築における基礎的なスキルの開発方法を紹介しよう。 仕様書を書くこと 最近のシステム構築では、仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成したり、システムを構築したりする手法が取られることも多いようだ。こういった手法
昨日、IT業界不人気の理由は? 現役学生が語るそのネガティブイメージに続いて「10年は泥のように働け」「無理です」――今年も学生と経営者が討論という記事が@ITに掲載された。どうにも理解に苦しむのは、自分たちが専門としている業界について、なぜネガティブな個所を強調した記事が大手メディアに連続して掲載されるのか、ということである。 まず、同座談会の@ITとITProの掲載記事を読み比べてみてほしい。同じ座談会でも、ずいぶんと印象の違う記事になるものだ。 ・@IT記事: 「10年は泥のように働け」「無理です」――今年も学生と経営者が討論 ・ITPro記事: 「IT技術者はやりがいがある仕事か」---学生とIT産業のトップが公開対談 しかし一連の@ITの記事は、特にネガティブに取れる箇所ばかりを意図的に取り上げているように思えてならない。釣り記事で注目を集めようということなのかもしれないが、釣り
以下はうちの会社の偉い人と私の、本当にあった怖い会話。 「ねーねーしんざきさん」 「はい?」 「これってさあ、今のシステムでもう一度つけらんない?(3年くらい前の別システムで実装されていた機能を指す)」 「へ。いやまあ、ちゃんと設計引き直せば、出来ないことはないですが(プチ修羅場のこの状況で何を言い出すんだこのオヤジは)」 「じゃあ、来週の役会で発表したいんで。何日で出来る?」 「は?(;゚д゚)」 「一度作ったヤツだし、コピペみたいなもんでしょ?なんとか来週間に合わないかなあ」 「寝言は寝て言え(←実際はもうちょっとオブラートに包んだ言い方)」 幸いなこと、私はシステム開発のスケジューリングについてある程度の裁量を認められているのでどうにかパリングに成功したが、もしかすると上の様な誤解は未だに一部でまかり通っておるのか、とちょっと疑念を持った。 上記は多分極端な例だと思うのだが。例えば営
Leon Bambrick / 青木靖 訳 2007年4月19日 木曜 新しい機能を見積るというのは・・・こちらに泳いでくる小さな魚のようなものだ。 小さな魚がくるぞ。 あの小さな魚を見て! あの魚小さいよ! あの魚なら食べられる! 一口で飲み込んでしまえそうだ! そんなに簡単だって、間違いない? もちろん簡単に決まってる! こんな小さいんだから! だけど前は間違ったじゃない。 うるさい、頭の中の声! この魚は小さいって。真ん前から見てるんだから間違いないよ! 一口だ。パクッ! それで終わり。朝飯前さ! 魚とは言えないくらいだ! ただの点だ! 小さな点! 小さな点を食べてやる! そら、魚が来る! 待てよ、なんか嫌な予感がしてきた。 もう遅いよ。約束しちゃったんだから。 魚を横から見たところ。 あーあ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く