フリーランスにおける仕事の断り方：生涯現役のITエンジニアを目指して：エンジニアライフ
2018年に20年勤務した会社をやめて、2019年1月に独立起業しました。現在、5期目に入っています。これまでいろいろな仕事のオファーがあり、私を悩ませてきました。 by nameでお仕事の依頼をいただけることは、大変嬉しいことで、悪い気がしません。しかし、自分の身体は1つしかないので、依頼された仕事をすべて請けることはできません。とはいいながら、依頼を無下に断るのも相手に悪い気がしていました。 結局、どうするのが正解だったのか？ 今回はそんなお話です。 取引額の大きな案件 報酬の額面がそれなりに大きなお金で、仕事の内容も片手間では難しそうな依頼についてです。金額の大きさ＝責任の大きさでもあるので、それ相応の責任も大きくなります。 たとえば、週3日の稼働で契約した場合、作業の遅れがでたり、突発的な障害対応が発生したりした場合は、残業や稼働日の増加をする必要があるでしょう。 よって、この手の
学校ではプログラミングではなくインフラエンジニアの知識を教えるべきだ：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 学校教育にプログラミングは必要ない もし学校でプログラミングを教えるとしたらどうなるだろう。まず、何の言語を教えるかでもめそうだ。無難にCか？いや、それも時代からするとちょっと違うような気がする。それともRubyか？流れが速すぎて、教える先生が死ぬだろう。脳みそが干乾びた爺どもが協議したら、真面目にCOBOLなんて決定が下るかもしれない。 学校でプログラミングを教えてほしくない理由は、開発の人に恨みがあるからではない。日本の教育と相性が悪いからだ。今の現場では通じないような古いコードの書き方を「正解」として教えられたら、現場で軋轢が増える。言語にしても、Javaを教えたら、Javaが「正解」になってしまわないだろうか。答えを一つに絞られて、融通が利かなくなる懸念が大
テレビのリモコンを孫の手で押すなって！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 弊社でやっているSQL講座の最初の方でお話しする内容です。 どれぐらいの人が試すのかな……、知ってる人にとっては極めて当たり前のことですけれど、知らない人は、けっこうびっくりする人もいるので、実際にやってみることを強くおすすめします。（できないという人はセミナーに来なはれ） では、ちょっとしたサンプルを作るか、それなりにデータ量のある既存のテーブルのインデックスを張ったカラムに対して、以下のSQLの実行計画を取ってみてください。 【注意事項】 実行計画を取る前に、Oracleは一応、アナライズをしておいてください。SQLServerは主キー以外のインデックスがある列を使うこと。 【準備】 SELECT MIN（カラム） , MAX（カラム） FROM テーブル
【１０】フリーエンジニアの末路：守銭奴エンジニアが考えていること：エンジニアライフ
こんにちは、手塚規雄です。 前回に引き続きフリーになって苦労する点について。今回は視点を変えて、将来苦労するだろうという未来の話、つまり年をとった後はどうなるのか？についてです。 ぶっちゃけた話、みなさんはフリーのエンジニアって何歳までできると思いますか？企業と契約をして働く形では、やはり50歳を超えると難しいと考えています。反対意見もあるでしょうが、中年のオッサンがリストラされると再就職が難しいのと同じで、それはエンジニアも厳しいことには変わりない。 サラリーマン時代の話ですがCOBOL技術者が必要になった時に、やっぱり50歳を過ぎた技術者は回避されがちでした。COBOLできる技術者で若い人が少ないとわかってはいましたが、それでもせめて40代なあ、みたいな感じだったのをよく覚えています。 なんだかんだ言って「若さ」というのはそれだけで強みなのです。もちろん50代でも現役バリバリの方もいら
実力を測るのにFizzBuzzも二分探索も使えない：Rails Hub情報局：エンジニアライフ
FizzBuzzをサービスにする「CodeEval」が面白い、というエントリーは、プログラマ採用に必要なスキル判定とリクルーターのマッチングをサービスとして提供するベンチャーの紹介でした。 しかし「良いプログラマ」というのがいるとして、それを見るのに、アルゴリズムのコーディングなんか必要なのか、そんなもので測れるのかという根本的な問題があるように思えます。 最近、RubyInsideで見かけた「Practical Tips for Hiring Ruby Web Developers」（RubyのWeb開発者を雇うための実践的なティップス）と題されたエントリは、まさにこれに答える内容で興味深いです。オーストラリア人開発者のTim Gohさんは、CのatoiだのQuickSortだのを書かなきゃいけなかったことなんて最近ないでしょ、Fizzなんてプロダクション環境で出力したことねぇよとして、
素人がWebサービスを作ってみて分かった9つのこと：Rails Hub情報局：エンジニアライフ
こんにちは、＠IT編集部の西村賢です。IT系のオンラインメディアで編集・記者をしております。タイトルに「ど素人」と書くと、ちょっと嘘になるので「素人」と書きましたが、素人がWebアプリを作ってみた体験談と感想を書いてみたいと思います。「オレもプログラミングを勉強して何か作ってみたい！」と考えている人や、「自分でサーバを借りて何かやってみようと思っていたんだよね」という人の参考になれば幸いです。 去年の夏、Webアプリケーション開発フレームワークのRuby on Railsのことを調べていて「面白そうだな」と思い、ドキュメントに従ってサンプルアプリをいくつか作ってみました。作ったり壊したりしている間に、こう思いました。 「あれ？ これなら自分が欲しかったサービスが作れちゃうんじゃないの？」 で、「Worklista」（ワークリスタ）という名前のWebサービスを作りました。3カ月ほど前から親し
ドメインロジックとSQL：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 旧聞ですみません。 ドメインロジックとSQLというのは、Martin Fowler氏というアジャイル・XPの提唱者の1人が書いたブログ一説です。そこから、SQLを考えてみましょう。 ■Martin Fowler氏のブログについて この記事はMartin Fowler氏のブログを読んで頂かないと理解できない内容かもしれません。 Rubyをやったことのない人はちょっと戸惑うかも知れないが、ぜひ、先ずはMartin Fowler氏のブログからがんばって読んでください。 今回、Rubyを使ってサンプルを作っている。いつもはJavaやC#（アプリケーション開発者が読めるC言語ベースのプログラミング言語）を使うのだが、まあいいややっちゃえーって思ってやってみた。Rubyを選
IT業界のシュールな現実（1）：下流から見たIT業界：エンジニアライフ
これから申し上げるのは、わたしが実際に仕事の上で経験したことです。これらは今日のIT業界の病根の深さを示すものです。 とある会社のシステム開発に呼ばれていったときのことです。まず見せられたのは画面見本でした。すでにHTMLで詳細な画面が作られています。画面数が多く、画面上の項目数も多い。これは相当意欲的なシステムだと思われました。これを実装できるなら、きっと充実した仕事になるでしょう。 ところがいつまでたっても開発が始まりません。誰がプロジェクトを管理しているのかもわからない。誰もスケジュールをはっきり説明できません。おまけにドキュメントサーバのどこを探しても基本設計書がありません。業務フローもなければシステム構成図もない。膨大なER図だけが公開されていて、ときどき修正されているらしい。 いつまでも遊んでいるわけにはいかないからと、詳細設計書を先に書くことになりました。基本設計書がないのに
言語は爆発する……らしい：プログラマで、生きている：エンジニアライフ
わたしは専門学校で FORTRAN を習って、就職してからも2年間くらいはずっと FORTRAN をやってました（たまに BASIC もやってましたけど）。 で、FORTRAN の仕事がなくなってきたから、という理由で C 言語を勉強するように言われたんですが、これがかなり苦労しました。カチカチした FORTRAN になじんでいたわたしには、C がとてもアバウトというかフリーダムすぎる言語に思えたんです。 なぜ = と == で意味が違う！ とか、なぜ *（アスタリスク）をこんなに使いまわしてる！ とか、なんかもう腹が立ってしかたありませんでした（苦笑）。なによりも頭を悩ませたのは、御多分に漏れずポインタでしたが。 当時はパソコン1台を複数人数で使うのが普通でしたので、お金を稼げないわたしはほとんどマシンに触らせてもらえず、本を片手に、先輩から出されたお題に頭を悩ませ、「これでどーだっ！」
「SQLが会話のペースでできるようになる！」わたしの勉強法：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 これができれば、SQLが会話のペースでできるようになる！（かも？）という、わたしの勉強法です。長いけれど、平易に書いたつもりなので、読んでいただければ幸いです。 ■ まずはプログラムの勉強法 わたしは裕福な家庭で育ったわけではないので、ファミコンも、ステレオも、ラジカセもなかった。 もちろんPCなんてなかった。 そんな小学生の頃、「中学生がゲームソフトを作って何百万儲かった！」なんてTVで見たのだろう。貧乏がイヤで仕方なかったわたしは「何百万」に即座に感化されて、雑誌（多分BASIC Magazineかな？）を立ち読みした。とはいっても、小学生の脳味噌でPCなしに雑誌を読むだけでプログラムが勉強できるわけもなく、「プログラムの前にフローチャートを書きましょう」と
テーブル設計は実装の後に！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル
上流の技術者はSQLを習得すべき：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 あっちこっちで書いていることですが、上流工程を担当するコンサル、SEの皆様、一度、以下の要望を聞いたとき、どのような提案をするか、見積もりをするか、思い浮かべながら読んでみてください。 客 きめ細かい顧客サポートをしたいので、以前より、当月の取引が落ちている得意先に営業をかけたいからリストアップして欲しいんだけど。 私 以前というのはどれぐらい前ですか？ 客 半年ぐらいと、今月の受注状態を比べられたらいいかな。 私 受注状態というのは、取引回数でいいでしょうか？ 客 そうだね、半年間の平均とこの1カ月間の受注額の割合を画面で入力できるようにして、××％以下の顧客を抜き出すようにしてもらえれば。 私 受注額ですか……。 客 あと、小さな消耗品は省いて欲しいし、商品
バッチ処理はSQLの一括処理で行おう！：ベンチャー社長で技術者で：エンジニアライフ
バッチ処理はSQLの一括処理で行うべきです。 しかし、バッチ処理を一括処理で行うときには一括でできる処理量の限界は存在し、それはマシンのスペックによって違います。限界を知っていれば怖くはありません。これまでも何度か、開発ではなく、テストや保守でも、SQLができるかどうかで大幅に工数が違うと書いてきましたが、それも合わせて、限界をみていきましょう。 条件はテストサーバがあって、本番と同じデータが入っているとしましょう。対象となるメインのデータの入っているテーブルをTableAとし、対象の処理は日次バッチだとします。 負荷テストの手順は以下の通りです。 現時点のピークを特定する ピーク時点のリソースの消費量を測り限界を予測する テストデータを作る 予想した限界量のデータでテストする ■ 1．現時点のピークを特定する まずは、本番と同じデータですから最も多くのトランザクションが起きている日を特定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
