リトルエンディアンにハマった件

とあるデータ解析ライブラリを使用してハマったのでメモ

ライブラリ自体は数値を入れてやるとバイト形式の値が返ってくるものなのですが、どうも出力されたバイト出力をうまく解析できない。

データ自体は16進数の羅列なので、1バイトづつPHPのbase_convertを使って2進数化してやって、あとはお好みで処理すればいいのだが、なんかおかしいぞ。

うにゃうにゃ調べること1時間、これってリトルエンディアンじゃね?と気づき入れ替えをしてやったら出ましたよ。

ということでリトルインディアンに関して整理しておこう。ほぼWIKIの内容だす。

多バイトで構成されたデータをどうやって並べるかをインディアンと言う

インディアンにはリトルインディアンとビッグインディアンがある。

ビッグインディアンはデータをそのまま読んでいきます AA BB CC DD EE  とあれば AA BB CC DD EE の 順番で解析していく。

逆にリトルインディアンの場合は EE DD CC BB AA になります。要は逆さまに解析してくださいってことです。

なんでこんな処理が生まれたかというと、そうゆうCPUが売られているからw

CPUは1バイト単位のレジスタでデータを処理するのですが、インテル系のCPUはリトルエンディアン(逆さま)で読み込む仕様だかららしいです。

なんでわざわざ逆さまに。。。と思いますがもちろん気まぐれでそうしたわけではなくて、メリットがあるため。

私的な理解では逆さまにすると、下位のアドレスから先に読み込むことになるのでオフセットを気にしなくていいのが理由なのかと思います。

どうゆうことか超要約して説明します。説明用のお話なので間違っていても許して。

たとえば 00123  という値と00022  という値を足し算しましょう。

ビックエンディアンの場合、オフセット部分を常に意識してやらないといけないです。オフセットっていうのは、この場合は左側の0を意味します。なおCPUは左から値を読み込むルールとします。この場合

  00143
+00082
=00225

いつも左側の0の数を常に気にしないといけません。

もしこれがリトルインディアンだと0を気にしなくていいのです。

リトルエンディアンでは逆さまなので 34100   と  28000  の足し算をすることになります。CPUは左から読み込むので0は無視してよくて結局

  341
+28
=522

左詰めで計算しています。繰上げは右にシフト。最後に逆さまを戻すと 225となってビッグエンディアンと一致します。

どうも0を気にしなくてよいということはCPUにとっては計算が楽になるらしいようです。

まあリトルエンディアンがいいかビッグエンディアンがいいかなんでどうでもいいですけどね。わたしはC言語を使った組込み系の仕事をしないので、動けばそれでいいです。

でもプログラミングする際にバイト配列が出てきたらコイツは逆さまなのか?は常に意識しておきましょう。

フリーランスエンジニアの仕事の取り方

フリーでやっているならば、仕事を切れ間なく入れていくことが大事です。

仕事が無い=無収入ですので

では具体的にどうやって仕事を取ってくるかですが、エンジニアの場合は次の4つでしょう。

エージェントを利用する
エージェント利用の最大のメリットは案件の数が膨大にあることです。IT業界はまだまだ景気がよいので仕事に困ることはありません。

しかし、希望する現場につけるかどうかはスキルシート次第。あと多重派遣という違法行為がまかりとおっております。そこを納得できるかですね。

パートナと組む
私の場合は前職の同僚が多いのですが、要するに営業さんやWEBディレクターさん、若しくは制作会社さんと組んで仕事をする形です。

勝手知ったるパートナーと仕事を継続していくので、やりやすいです。一番オススメ。

でも、やりやすいのが仇となって、仕事が特定の人脈に固定されます。人間関係に何かあったら大変です。

案件を紹介してもらう
フリーのエンジニア仲間とか知人友人、ちょっとした知り合いから仕事を紹介してもらう形です。新規開拓にはこれが一番

でも、普通は紹介なんかしてくれませんよね。私だってしません。なので必ずキックバックすることを伝えましょう。

受注金額の2割を紹介料としてお支払いしますと言えば、思い出してくれる確率は高まります。

ただし、あくまで初回限りの紹介料ということで、再度の発注に関してはお支払しません。

ブログ・SNSから集客
これって結構大変です。今でも仕事の割合としてはほとんどないです。問い合わせはたまにありますがビジネスにはならないですね。

まだブログの集客力が弱いってもあるのですが、個人的には開発が必要な会社さんがエンジニアを直接ネットで探すってことはあまり無いんだと思います。

なので先に書いた、パートナーや案件の紹介者と、このブログをきかっけに知り合う形を目指しています。

名刺にこのブログのURLを記載しているので、直接会った人にブログを読んでもらって、もっと知ってもらうっていう使い方もしています。直接会った人は結構このブログを読んでくれているようです。

 

ブログには書きたいことを書けばいい件

今日はこのブログのスタンスをちょっと書いてみます。

実は私はこれまで2回ほどブログを立ち上げては閉鎖を繰り返しております。理由は簡単で、ネタが無くなるからです。

最初はプロマネの話題で書いていました。その次はAI系の話題で書いていました。でも

ネタ切れ=>放置=>誰も読まない=>閉鎖

を繰り返し。。。。

なのでもうテーマの縛りはしないことにしました。ブログのセオリーだと何か専門性がないと読者にメリットが無いからダメというお説教がありますが、そんなの無視無視

書き続けなければアクセスは集まらないのです。なので書きたいことを書きたい時に書くだけです。

記事の文字数も最低でも2000文字とか言われますが、そんな制約があると嫌になるのです。なので好きな長さの記事にします。

ただ、今日こんなもの食べたました!とか、こんなところ出かけたよ!なんて書いても誰も興味ないし、自分も書きたくないので、そうゆう意味なし記事はNGになってます。

ほとんど縛りがないのでプログラムの話から英語の話まで、脈絡なく書かれておりますがご理解のほどお願いします。

基本は何も変わってない件

今日はおっさんエンジニアのたわごとです。

タイトルの通りでIT技術は次から次に新しいものが出てきているのですが、実は基本は何も変わっていないのです。

例えば車で考えてみましょう。車を構成するのは

タイヤ  シャフト  エンジン ハンドル ブレーキ

これって車が生まれたと同時に生まれて、基本的な機能は変わっていません。

同様にITの世界も

2進数計算 CPU メモリ ディスク TCP/IP  HTTP

と、こちらも基本技術はここ20年でほとんど変わっていません。

変わっているのは開発言語や、ミドル以上で動くソフトウェアなのです。ハードの容量と速度が上がってきたので、それに合わせてソフトも進化しましたが基本的な部分は何も変わらず。

今ではクラウドとかAIとかが話題になっていますが、それも基本技術の延長線上で実現されているものです。

再度、車で例えると、ギアがオートマになったとかナビが付いたとか電装系が進化したとか、そんな感じです。

クルマの基本構造は何にも変わってない。

ということを前提にして、これからITエンジニアになりたい人に伝えたいのは、まずは基本的な知識を知っておく方がいいということ。

昔はパーツを組み合わせてパソコンを作ったりしましたが、今はノートが基本なので、ハードをじかに見る機会が減っています。特にサーバはクラウドが基本になっていくので、サーバというものが物理的なコンピュータであることすら理解できないかも。

だからこそ、基本的なITの構造を知っているかどうかで、エンジニアの伸びしろが変わってくると思う訳です。

基本構造を理解して使うのか、構造は理解してないけどとりあえず動かせますというのか。。。

今後、エンジニアにフルスタック的なスキルが求められていくのであれば、基本的な構造を網羅的に知っておかないとフルスタックな対応はできません。

では、どうすればいいか?

基本的な技術に関する書籍を10冊程度読めばよいと思います。重要なのは言葉を覚えるのではなくて、WIKIでもなんでも使って腑に落ちるところまで構造を理解することです。

まあ、優秀なエンジニアが少ない方が、私的にはライバルが減っていいんですけど、年を取ったので説教くさいことを書いてみました。

 

 

 

開発で良く使う英語表現

今は外国人と開発をする機会は減ったのですが、会社員の時は必要に迫られて勉強してました。いくつか表現をため込んでいたので、ブログのネタにします。

正しいかどうかはよくわからないが通じていたので、まあ大丈夫でしょう。でもここは英語のブログじゃないので間違ってても私は知りませんよ。

レッツスタディ!

なるべくしないように
Try not to copy the data. OK?

しないほうが良いと思うけど
I dont think you should leave the bug, otherwise you would forget it.

まもらないとまずいよ
You are going to get in trouble if you dont obey the cording rules

確認した?
Are you sure you checked the format?

ちゃんとやってね
Make sure you do it right.

2時間かかる
This program runs for 2 hours

5分間隔で
This batch job runs at 5 minute intervals

この順番で
Keep checking in this order

同じ方法で
You can solve this problem in the same way

共通化して
try standardization of these classes

構造
You have to design the structure first!

プロトタイプ
Lets make a prototype and show it to customers first

条件
If this value fulfill the requirement on this branch

仕様
This specification is wrong! You have to correct it right now!

見積もり
Make an estimate of the cost first,then assign programmers next

稼働率
We must keep a 99.9% rate of operations on this server

減らす
We must reduce the workload of the members

検出
We need to detect latent errors in the system by this method

工程
Put 10 people at process A

整合性
There is no consistency with documents

外注
This project needs some subcontractors

人月
This project needs 10 man-months in 5 months

ボトルネック
I have to identify the bottleneck until tomorrow

不一致
Fix the discrepancy between A and B

対策
Lets think about the countermeasures for delaying

もう帰ろう
Lets call it a day

どうなってる
How is the project A going?

 

That’s all

 

PHPでもJAVAでもなんでもいいんだけど

プログラマによくある神学論争のお話

JAVAがいいとかPHPだとかRUBYだとかプログラマが自分の愛好する言語を溺愛して他をケナスってことがありますが、これって意味が無いというかどーでもいいことです。

正直お客さんにとっては何でもいいんですけど。

お客さんの要望や課題を安く解決してくれる言語であればそれがベストな言語なのです。

実際にエンドのお客さんが言語指定することってほとんどないです。あるとすれば他のベンダーのシステムもサーバに入っていて、統一する為に特定の言語を希望されることはあります。

もちろん言語によって得意不得意があって、本来はその用途によって適用される言語が決まるわけです。なので言語の優秀性を比較してもあまり意味ない。

例えば銀行のオンライン決済サイトでPHPってのは向いていない気がします。ここはJAVAを使うほうがよいかと。

でも単なるECサイトならPHPで十分

要は堅牢性に関してはJAVAに軍配があがるって話です。じゃあJAVAで全部作ればいいじゃんとなるのですが、サクッと作るにはJAVAはあまり向いていない。

なので、どんどん仕様が変化するECサイトではPHPやRUBYが有利だったりします。

では用途が似ている言語ではどうでしょうか?たとえばPHPとRUBYは両方ともライトなスクリプト言語で有名です。用途も似通っています。

個人的には、自社開発ではRUBY、受託開発ではPHPがよいんじゃないかと思います。

RUBY人材はあまりいないので、受託開発で一時的に人を集めるようなプロジェクトには向いていないのです。調達のしやすさでPHPに軍配が上がります。

逆に自社開発では超急ぎの構築なんかもあり、RAILSがつかえるRUBYの方が有利だと思います。

でもケースバイケースなのでなんとも言えません。

ともあれ、どの言語が良いかというのは神学論争でしかないので、あまり関わらないようにしましょう。

ITのお仕事でAIで仕事を奪われる部分

AIで仕事を奪われるとかいう記事がちょいちょい出ております。その中で先日興味を引いた記事は、現実に仕事を奪われるのはブルーワーカーではなくてホワイトワーカーだよ、というお話し。

元ネタどこだかわからなくなったのでリンクできませんでした。だいたいこんな感じの内容でした。

たとえばパートのおばちゃんはAIに置き換わりません。そもそもパートのおばちゃんの給料は安い、安い割には汎用性が高いのでAIやロボットに置き換えられるのは50年先。

汎用性というのはどういうことかというと、レジを打ち、掃除をし、商品を陳列し、お客さんのクレームを聞く、という複数の作業を一人で行えることです。

しかし、これ全部AIやロボットで置き換えるとなると莫大な費用がかかります。なのでパートのおばちゃんは安泰なのです。

一方で、レントゲンなどの画像診断を行う技師の仕事は相当ヤバいです。AIがもう使われ始めています。

診断結果は最終的には人間が判断する必要はあるのですが、スクリーニング段階はAIが使われます。なので必要となる技師の頭数は減っていきます。

同様に専門職である弁護士、司法書士などもクライアントと対峙する部分は今後も人間がやる必要がありますが、バックヤードでの仕事、例えば過去の判例を調べたりする部分はAIが代行するようになるそうです。

弁護士というよりもその秘書とか資料を用意する事務方が要らなくなる感じでしょうか。

つまり一番AIに置き換わる可能性が高いのは専門職の中のルーティン作業を受け持っている人々になります。

ではIT業界ではどのパートがヤバいのか?

コンサル、PM、SEの3職は安泰です。これらはクライアントとのコミュニケーション中心のお仕事になりますのでAIに置き換えができないと思います。

部分的にAIを使ったツールで合理化されるでしょうが、大勢に影響はない。

ではプログラマは?こちらはちょっとマズそうです。プログラマにも2種類あって、SEを兼業しているようなプログラマに関してはむしろ朗報かもしれません。

SEとプログラマの境界線がなくなってプログラマがお客さんの要件を直接聞いてAIに実装させるという理想的な状態になるかも。

一方で、詳細設計書がないとプログラムを書けない、プログラマではなくてコーダーと揶揄される方々はAIに置き換わるかもしれません。

テストに関してもSEがテスト設計を行ってあとはAIがテストをしてくれる状態が実現するかもしれません。

実は今までも自動コードとか自動テストとかは研究されて、販売もされてきましたがなかなか普及しませんでした。さまざまな制約がありすぎて適用できるケースが少ない。

もしAIがこれらの自動化を本当の意味で実現するとなると、いわゆるIT土方と言われるコーダーやテスターはお払い箱になります。とはいえ、テストツールを実行したり、AIが生み出したバグ取りをしたりする作業は残るでしょう。

この職種はパートのおばちゃん同様、一人で雑用を何役も兼ねる安月給なIT土方かと。

まとめますと・・・・・

クライアントと直接話す部分(SIで言う上流ってやつ)に関しては今まで通りだと思いますが、いわゆる下流の仕事はAI利用が普及します。それをメンテするIT土方だけが生き残る世界になるかもしれません。

 

とここまで書きましたが、AIがプログラムを自動で書いてくれるまで、まだまだ時間がかかりそうなので、私世代は逃げ切れるかなと楽観視しています。

社会人MBAは損か得か

私は早稲田大学がやっている社会人向け夜間MBAを卒業しました。結構な値段の授業料を払ったのですが、それに見合ものがあるのかどうか書いてみます。

そもそも論ですがMBAという学位は日本ではあまり評価の対象にはなりません。

もしあなたが今の会社に一生居続けるつもりなら別にいらない思います。たぶんMBAに行っているヒマがあったら社内で頑張ってくれよいうのが会社の本音かと思います。

では転職の場合ですが面接官次第ですね。まあ努力家である証明にはなると思いますが、そもそもMBA出た人って何ができるのかピンとこないので、それ以上の評価は難しいかもしれません。

逆に仕事ほったらかして資格をとっていたヒマな人と思われる可能性もあります。

なのでMBAという肩書自体は社会的にはあまり価値が無いかと思います。無いよりはあったほうが良いですが費用対効果が悪すぎます。

では実際に学校に通って得られるスキルに関してはどうでしょうか?

正直授業のうち、半分くらいは座学主体なので自習でも代用可能です。自宅で勉強がぜんぜん可能です。

むしろ実地研修(討論だったり発表だったり企業訪問だったり)がMBAでなければ受けられない内容だったりします。これはさすがに自習できません。

でも、それでできるビジネスマンに成れるかはわかりません。所詮はケーススタディでしかないので現実とは違うと思います。

けど視野が広がることは確か。

私個人としてはエンジニアとしてずーーと働いていたので、いろんな世界が見れたことは有益だったと思います。

なぜ経営者がエンジニアを奴隷のようにこき使うのかも理解できましたw

それとは別に統計学を学べたことと起業に挑戦できたので個人的にはあまり損したとは思っておりません。

でも、あの時間と費用をもう一度投下するかと聞かれたら、NOです。

むしろあの時期、情報科学系の大学院に行って機械学習をみっちりやっておけば、今頃はもう少し高単価の仕事ができていたかもしれない。

でも、これは今時点の判断で5年後にAIブームは完全に死んでいるかもしれないし、MBAで学んだことが5年後には役立っているかもしれません。

もしアナタが、これから起業したいとかキャリアを変えたいと思っていて、でもどうすればいいのかわからない場合、MBAは何かのきっかけにはなります。これは保証します。

2年間、勉強しながら次のキャリアを考えてみる。起業のアイデアを固めてみる。

特に起業したいのであれば先生たちがさまざまなアドバイスや、時には助力もしてくれるでしょう。

でも、既にやりたいことがあるなら時間とお金の無駄です。やりたいことに一直線でがんばりましょう。

ということで結論としては

これからどうしようか迷ってる人が、きっかけをつかむ場所としてはオススメします。

でも、特に迷っていない人は行かない方がいいです。時間とお金の無駄です。

行動的目標を実行しよう

こないだ厚切りジェイソンさんのインタビュー記事を読んだんですが、是非読んでみて欲しい。

https://townwork.net/magazine/life/21235/

特にこの中で、結果的目標ではなく行動的目標を重視するってのは激しく同意です。行動的目標ってのはこの記事からまるまる引用すると

「例えば、10kg痩せようとして、1年後に達成できてなかったら失敗と思うのは間違い。成功は「将来」ではなく「今」なんだよ。10kg痩せるために毎日10分間マラソンをすると決めたら、今日、マラソンを実行できたかが大切。つまり、結果的目標よりも行動的目標の方を重視すべきなんだ。毎日10分走るという行動的目標をコツコツ積み重ねていれば必ず痩せて、最終的な結果につながる。」

の部分です。

別にこの記事を見たから、じゃあこれからやってみようと思ったわけじゃなくて、私も既に英語を勉強したり、新しい技術を勉強したり資格を取ったりと、勉強を継続させる時にはこの方法を実践しているからです。

元々は英語の勉強がなかなか続かなかった時に読んだサイト http://mutuno.o.oo7.jp/07_continue/07_continue.html

のこの部分を参考にしておりました。

何度目かの挫折を経て、またジョギングを始める際、私は図書館で見つけたジョギング指導書のアドバイスに従ってみることにしました。まず、初日は数百メールで切り上げです。初めの一週間は距離を増やさない。ジャージに着替え、ジョギングシューズを履いて、外に出るものの、ほんの10分もしないうちに帰ってくるのです。次の週は少し距離を伸ばすものの、少しでも息が切れたらそこでストップです。

そんな風に徐々に距離を伸ばしていきます。とにかく苦しい思いをしない。疲れたらやめるのではなく、疲れの予感が来た段階で走るのをやめてしまうのです。物足りなさを感じるくらいのところで切り上げるのが味噌です。こんな風に続けていくうちに、まずジョギングに対する気の重さが全く無くなってしまいました。ジョギングは果たさなければならない義務ではeなく、一日の終わりの快適な気分転換に変わりました」

要するにあまり大風呂敷を広げて高い目標を設定しないってことですね。もちろん最終的な目標は持ってもいいのですが、それよりも毎日の小さな目標を継続することが大事だと思います。

IT技術とか英語とかってのは、地道にやってれば誰でも上達できるタイプの技能です。特別な才能は必要ないので行動的目標にとってもフィットしています。

ただブログの継続に関してはこのとおりってわけでもない気がしてます。そもそも書くネタもないのに毎日無理に何か書くということは意味が無いと思うので。無理に書くとなると今日食べたものをアップしたり読者が全く興味をわかない日記記事にならざるを得なくなります。

とはいえ、継続こそがブログ成功の本質だと思うので、ちょっとでもみんなに役立ちそうなネタは書いて行く予定。

今日のブログ内容はまさにそんな感じのものになります。

おいしいところは人にあげちゃう件

営業活動をパートナーに丸投げする際、気をつけたほうがよいことがあります。

それは最終的にいくらで売れたのかを知ろうとしないこと。

何を言ってんだコイツ?という意見もあるかもしれませんが、私的にはこれでいいのだ。

私は欲深い人間です。なので自分の取り分がわかってしまうと、きっと不満をもつと思います。

俺が作ってんだからもっとよこせ!

理屈では自分が設定した請求金額どおりに頂ければ満足するべきだと思います。でもアタマで分かっていても、なかなかそうはいかないです。

ならば最初から知らない方がいいのです。

人は誰でも自分が一番得したいと思うし、それがあたりまえだと思います。しかしそれを主張してしまうとパートナーとの戦いになります。

そんな関係は長期にわたっては続かないし、ケンカ別れしてしまったら次の営業パートナーを探すコストがかかります。

おいしいところはあげればいいのです。自分は残り物をありがたくいただく。

そうすれば漁師はもっと魚をとって来てくれて、WINWINな関係になります。

もちろん自分が欲しい金額もらえないのであれば、違う漁師を探す必要がありますが、満足できる金額を貰えるならば、それで満足しておくに限ります。

というわけで、WEB制作会社の方、フリーのWEBディレクターの方、WEB開発会社の方、損はさせませんのでご連絡お待ちしています。