眠る開発屋blog ある開発屋の雑感。日々勉強。

2009/4/13 月曜日

自動化とか

Filed under: 技術メモ — タグ: — dev0000 @ 1:35:46

SIerに自動化が浸透しない話。

『ずっと受けたかったソフトウェアエンジニアリングの新人研修』続き

本書で対象としているのはおそらくSIerとかだと思います。よく知らないけど。システム化を提案する立場の人が、自分自身の業務がシステム化、自動化されていないようでは、紺屋の白袴にもほどがあるんじゃないでしょうか。実際の現場ではさまざまざまな制約があってそういう風にもいかないのかもしれません。でも、何も知らない新人に対して「研修」の名の下に教えることとしては、もう少しちゃんとした開発方法を教えるべきです。それが開発に携わる先人としての義務でしょう。

青は藍より出でて

実証実験にはえらく金(スポンサー)と人手がかかるというのが一つの原因かなぁとか考えてみるのだが、スポンサーには困らないはずなんだよな、というか国(それが可能なスポンサーだろう?)は発注者として、そこまで踏み込んでみたらどうだろうか(でも、失敗した場合の追及され度が現行踏襲よりでかい、失敗を許さないシステムというシステムがあるためにそれが難しいのならば、まずそこからリストラクチャしなければならないのかも、とかも思う)。

人月だから自動化推進の動機付けが生じないんです。例えばスタロジの自動化技術を買うSIerっていないんですよ。理由が「自動化されると人月が減って売上が下がるから」。これマジ話。ここに工事進行基準(人月前提)が絡むともう…。

紺屋の白袴

って,はぶさんのコメントが的を射ているんだけどね。コンピュータの使用料が人件費より高かったウン十年まえならいざ知らず,今でも多くの人の手垢にまみれさせる事が高品質化の秘訣だと思ってるからナー。

ま,実際の話,ある程度の頭数が揃わないと商売にならないってのも分かるんだけど,ピンで売れない高技術者集団抱えてどうすんだって話もある。おっと話がそれた。:-P

まぁ相場を上げてくれる企業が存在するからこそ、
「相場の半分の費用を請求し、4分の1の費用で制作する」
というワザができるわけで。

新人研修に必要なことってなんだろね。
技術についての世界観の説明とかなのかね。

マスターとか

Filed under: 技術メモ — タグ: — dev0000 @ 1:11:03

そもそもマスターするなんてありえない。

「プログラミグ言語を理解するにはどうしたらいい?」という話を聞いて思うこと
プログラミング言語をマスターするということ

Web系言語は最近でこそ変化のスピードがやや遅くなった気もするが、
変わり続けるものであれば、マスターするという概念はあまりないような。
キャッチアップし続けなければ、仕事としてはやっていけない。

2009/4/6 月曜日

言語とかラボとか

Filed under: 技術メモ — タグ: — dev0000 @ 3:16:48

経営者にとってのサーバサイド技術選び

まぁ信頼できるエンジニア確保したら、そいつにやらせたい言語やらせるのが一番いいとは思うけどね。
「DB連携したWebページ生成技術」ということではどれもあまり変わらないだろうし。

使用言語で職場を選ぶか?と問われると、それは選ぶだろうね。
昔は「なんでもできる奴がえらい」みたいにも考えていたけど、
一つの言語を深堀しない職場って、受託営業的にはラクだけど、習熟度がなかなか上がらないので、生産性はどうしても下がるからね。

開発会社が途中で放り投げる案件って、PHP+流行のフレームワークが多い気がする。
多分、簡単にできちゃうように思えるから、初心者集めてエイヤみたいなプロジェクトになることが多いのじゃないのかな、と妄想。

あとあまり関係ないけど、apc でチューニングってところまでになると、イメージ的にはJavaVMの起動パラメータのチューニングに近いのかね。
そこまで頑張らなくても、とりあえず動いてくれるのが楽しいところではあるけど。

それに個人的にはラボとか事業と関係ない制度でエンジニアに機嫌を取る必要ってあるのかな?とはむしろ思ったりする。

1つは広告効果なんだろうけど、これは最近ブームが確かに過ぎてるだろうし。
もう1つは社員の技術に対する向上心育成か。
放っておいても勝手にやってくれる文化が形成されているところは幸せだけど、そうじゃないところはどうにかして火をつけなきゃいけないだろうし。
ただ、刺激を与えるような人がいて、それが周囲に影響を与えれば済む話のような気もする。
文化という大げさなものでなくても、組織が小さければ、一人の人間の存在で大きく変わってしまうものだからね。

あと、PHPがよくdisられているとか言うけど、最近はPHPを使う人がPHPをdisることが多いので、それはそれで健全だと思う。

2009/3/18 水曜日

機能外要求とか

Filed under: 技術メモ — タグ: , — dev0000 @ 1:48:44

たまに思うのは、
「そんな大層なサマリー機能作るんだったら、『できるシリーズ』のExcel本買って、担当者が使えそうな関数を覚えたほうがコスト安いんじゃねぇの?」
とか。
ただ、入力処理やトランザクション処理などデータ更新機能と、
サマリー出力などのデータ集計機能は分けて考えた方がいいよね、とか思う。

まぁそれはともかく。

機能十分、要件不十分

稼働開始早々、誤操作によるデータ不備の頻発・必須データの増加で入力効率の低下 とかで社内中てんてこ舞い。複雑な内部処理のためかシステムのパフォーマンスにも問題が発生。
結果、しばらくの後、社内協議の上 旧システムに戻してプロジェクトはなかった事に。費用ン億が時間とともに水に流れた。

このパターン、どのくらいの人が体験済なのだろう。

「しばらくの後」ってのがどのくらい後かによるんだけど、
最初は手間取るんだけど、3週間もすればルーチンワーク化してきて、
それなりのノウハウ(バッドなのも含め)を蓄積し、
それなりの作業時間におさまるってパターンが多い気がする。

出来上がったシステムは、要望のあった機能は十分満たしてたよ。でも一つの大切な要件が不十分だったんだ。それは、社員の作業の効率向上を図ること

ってか、これって機能外要求がきちんと定義されてなかった、ってことなのかな。
このへんをすっ飛ばすと、ボタンを押した後、10分たってようやく次画面に遷移するような素敵なシステムが出来上がる。

2009/3/15 日曜日

10個の禁止事項とか

Filed under: 技術メモ — タグ: — dev0000 @ 14:32:26

なるほろ。

WEBプログラマ向け、10個の禁止事項
何となく気になるので突っ込み

1. 車輪の再発明禁止
commonsやCPANに同様の機能があることに気づかずに、自前で実装したりしない。後で全く同じ機能が存在することに気づいてショックを受けたりしない。必ず一度同じような機能が落ちてないか確認する。

まぁライブラリ確認したほうがいいよね。

2. 言語的冒険禁止
PHPで組んでと言われた時に「Pythonにしましょうよ」とかわがまま言わない。「それがダメならRalsで」とも言わない。Perlでやるべきことを「シェルで挑戦してみた」とかも言わない。

エンジニアのモチベーションを維持する為に、チャレンジングなことはある程度認めたほうがいい気がする。
が、「それって会社の利益にどうつながるの?」ぐらいは説明させてもいいかも。
もしかすると「趣味で一度組めば納得する範囲」なのかもしれんので。

3. 死ぬほど働くの禁止
栄養ドリンクがないと乗り切れないような生活を1年中続けたりしない。適度に息を抜いたりサボったりする。2ヶ月以上連続して張り詰めるとヤバイらしいから気をつける。

そら禁止だ。

4. 新人に優しくないソース禁止
WEB 系の職場は、ビット演算や排他的論理和を使うと一部の人から「読めない」とクレームが出る世界らしい。遺憾ながら控える。Windowsプログラミングでよく使う、数値の32ビットそれぞれに意味を与えてAND演算で判定するのも通じないから駄目らしい。恐ろしい世界だけど、それに慣れる。

Web系のオープンソースプロジェクトとかライブラリのコード眺めていれば雰囲気が掴めるはずだけど、
ビット演算とか排他的論理和ってWebエンジニアからすれば「トリッキーなコード」にしかならない。
大体、PHPとかだと、C言語の構造体ビットフィールドみたいなものはないわけだし、そこまでビット対応可能な言語とは思えない。
これは慣れるしかない。

5. 英語苦手意識禁止
調べごとをする時に日本語のページばかり読まない。時間に余裕がある時は英語のサイトを優先的に読む。英語力はしばらくサボるとすぐ落ちるから気をつける。英語に触れやすいように、Googleの検索パラメータのjaなところをenにしておく。

必要になったら頑張って英語ページ読むけど、日本語で情報が見つかる場合はそれで済ますことが最近多い。
そこまで難しいことを要求されているわけじゃないからかもしれん。
ってか、日本語資料の乏しい要素技術って、そこまでは枯れてないという印象があるし。

6. リファクタリングのやり過ぎ禁止
ちょっと実装が早めに終わって時間が余った時に、リファクタリングを始めたらつい楽しくなってしまって、気が付いたらスケジュールに遅れが出ていたとか厳禁。適度なところで我慢する。

まぁ進捗が遅れるのはよくない。

7. 寝不足禁止
睡眠不足の時に、ポメラと戯れたり、ブログを更新したり、いらんプログラムを組んだりして無為に時間を使わない。さっさと寝る。

確かにそうなんだけど、逆に仕事し過ぎて、就寝時も頭が冴えちゃった場合はどうしよう。
酒飲んでおけばよいのかな。

8. Firefoxベースで考えるの禁止
Firefoxだけで表示確認をして終わった気にならない。どれだけ嫌いでも、どれだけ憎くても、ちゃんとIEで見る。Chromeで見てSafariを確認した気になるのは……まぁ、JavaScriptをゴリゴリしてなければ、いいか。

動作保証環境にどういうブラウザを含むか?という話だけな気がする。
個人的には「Safariでの稼働保障」というのは、見積もりに上乗せしていいレベルのような。

9. 調べごとに没頭し過ぎるの禁止
それほど優先順位が高くない調査事項と相対した時に、調べ始めたらハマってしまって必要以上に時間をかけすぎるのは禁止。どうせハマるなら優先度の高いことにハマること。でも、調べもせずにすぐに諦めるのはもっと禁止。

「いつかは絶対に調べなくてはならないこと」だと、中断するロスもあるわな。
分からないときは代替技術にさっくり切り替えるのも手。

10. 仕事中のネットサーフ禁止
仕事中に仕事と関係ないニュースサイトを見るの禁止。朝、仕事をする気が起きなくてネットサーフしていたらいつの間にか昼休みになっていたとか厳禁。この項目を見て「これを禁止するのは私には無理だ」とか思うの禁止。

何をもって仕事と関係ないとするかが難しい。

2009/3/8 日曜日

天才って作れるのかねとか

Filed under: IT世間話 — タグ: , — dev0000 @ 22:17:15

天才って作れるのかね。

天才プログラマー/スーパークリエイターになる方法(1) 立志編
5年以内にQITOからスーパークリエイターを出すために

なんというか、天才を作れた仕組みって、トキワ荘システムぐらいしか思いつかない。
似たような方向性だったり、スキルを持った人々が切磋琢磨しあって、時代を代表するようなモノが幾つも出てくるとかそんな感じ。

まぁいいんだけど。

2009/3/2 月曜日

タグのidとか

Filed under: 技術メモ — タグ: , — dev0000 @ 2:32:03

なんか前も書いたかもしれんが。

HTMLのタグにはid属性だったりclass属性だったりが設定できて、CSSの指定でもそれらを使えるわけだが、同一ページ内でidが重複しているのはどうもね。

ってか、これって結構多い気がする。
idを重複しないように適切に使っている方がむしろ少ないぐらい。
重複箇所をエンジニアのほうで修正すればいいのかな。
でもそれの手間隙ってどうなのよ。

思うのだが、CSSで使うだけであれば、idの使用を禁止して、classオンリーで記述するように縛りをつけてもいいんじゃないか。
HTML+CSSが書けなくなることもない筈だし、idの重複を気にしなくても済む分、そっちのほうがいい気がする。

画像とか

Filed under: 技術メモ — タグ: , — dev0000 @ 2:23:48

Webページ制作とかで、
テキストとスタイルシートで表現しても問題ないような箇所を画像にしちゃう風潮はどうにかならんかな。
画像は確かにブラウザごとの見え方の違いを吸収しやすいから便利なのだろうけど、
文言の修正にすごく弱いのだよね。
いちいち画像修正するのめんどうだとか、外注のデザイナーへの差し戻しになれば、更に時間がかかって仕方ないとか。

2009/3/1 日曜日

プロキシサーバーとか

Filed under: 技術メモ — タグ: — dev0000 @ 12:44:33

最近、思考停止していた。
そっか、プロキシサーバー。

pg_pconnectに気をつけろという話に気をつけるべき理由
っで,エンジニアはどこまでやらないといけないのか書いてあげないの?

で、そこまでわかっている人間が誰かに伝えるべきことは、pg_pconnect使うと障害対応で人間やめることになるよなどという意味不明な極論ではなくて、例えば「PHPスクリプトを動かすhttpdと画像やCSSを送り出すhttpdは別にしよう」ということだ。知らずに思考停止しているだけであればまあアレだが(笑)、知っててなおシャレや冗談のつもりで話しているならば誤解を招きすぎである。

そうですね、初歩的な基本なんですね。。。

でもまぁ少ない予算でやりくりしているとどうもなぁ。
アクセス数の割にはそこまで売上が上がっているわけじゃないし。
でも構成見直したほうがいいのかな。
プロキシサーバー追加したほうがいいのかな。

ってか、PostgreSQL殆ど 使ってないし。

そもそもPostgreSQL 使う状況って自社企画より業務案件のほうが多くね?ってイメージがある。
つまりそうはなかなかリソースを増やせないとか。

2009/2/14 土曜日

お行儀のよいDB設計とか

Filed under: 技術メモ — タグ: — dev0000 @ 1:33:55

「よくあるよくある」というか、なんとなくどっかで見かけたような「お行儀のよいDB設計」というのがあって、それについてのメモ。
ちなみに想定しているのはmysql。

会員の名前や住所、職業、電話番号もフィールドの長さを個別設定

varchar(100)とかちゃんと適切な長さを設定してたり。
お行儀がいいと言えばいいのだけど、
そういった長さで悩む時間が勿体ないので、僕はtext型にしてしまうことが多い。
別に検索対象となるわけでなし、リアルタイムでサマリをかけることも殆どないし。
レコード数が膨大になればこれは真面目にやらんといかんのかな。
ってか、個人的な業務の範囲内だと、
一昔前のサーバークライアントシステムっぽいのならともかく、レコード数の数がサーバ容量を逼迫する状況って、アクセスレコードぐらいしかないかも。

主キーとは別に外部キーとなるコードがある

シーケンシャルなIDはあるのだけど、それとは別のコード体系があるとか。
そもそもこのDBとは別のところによりマスタなDBが存在して、そことの整合性を保つ為にあるんだろうな、と想像することにする。
・・・それも考えにくいか。
論理削除を採用した場合、シーケンシャルなIDをそのまま採用できない、とか?
でも自分自身、論理削除ってあまり使わないので、これは憶測。

主キーの名称が「テーブル名 + ID」になっている

たまに見かける。
RailsとかCakePHPとか昨今のフレームワークだと標準で「ID」決め打ちだったような。

僕自身は「アプリケーション側にリスクをもたせる」発想みたいなので、DBに対する考え方はなんかゴワゴワに。
でも怒られそうだな。

ただ「お行儀のよいDB設計」って本当によく見かけるというか、
どっかのベンダーが当初作った物を皆が参考にしてしまった(或いは仕様として渡されたから)こういう似たような形式になっているとか。
UTとかPTとかテストフェーズの呼称は系列ごとに方言化している、という話を聞いたことあるんだけど、それに似たような状況なのかな。

「お行儀がよい」というのは「品質が高い」ということかもしれんが、
それはそれだけでコストに跳ね返ってくるもの。
設計段階で過剰品質を発生させてしまうと、コーディング時には数倍〜数十倍の余計な手間隙を生んでしまうものだし、
だから設計を行う人が凝り始めるとそれはそれでよくないかな、と。

まぁでもテーブル設計のシートに「データ型」「データ長」ってカラムがあったら、
どちらも適切な値を埋めたくなるよね。

« Newer PostsOlder Posts »

Powered by WordPress