楽になっているはずなのに大変になっている?
昨日に引き続き環境構築中に感じた事ですが、色々世の中便利なものが増えている「ような気がする」のですが、実際にその便利は使いこなせた人しか手に入れる事が出来ないのが現状ではないかな?
というのもrailsもそうなのですが、これ以上に便利なはずの言語Lispって実際これを使ってビジネス構築出来た人達はあまりいないように感じます。
Cやjavaに比べてですけどね。
ただ、開発効率が非常に高い言語が使えると、10人でやっている仕事を1人でこなしてしまうという状況が作れます。
また、コードが10万行のコードが必要なモノが1万行まで減れば見やすさも向上するので、出来ると出来ないとでは雲泥の差が生まれてしまうのですね。
大体、今の時代で成功しやすいのはこの効率の高い状況を作る事が出来るrubyなどの言語なのですが、完全にこれは言語に対しての投資だと思います。
投資先を何処にするかで、その後の自身のポジショニングがすっかり変わりますからね。
ここを頓着すると、非常に残念な結果になるので僕自身はどうにか突き抜けないと行けないと考えています。
たまに、同業者と話すときがあるのですが、いいサービスを作る人達とダメなサービスを作る人達では全く思考が違います。
見えている景色が違うからなんでしょうね。
これは独立してやっている人間が会社員と話が合わせづらい時と同じ感覚を味わった事があります。
まぁ、何処を目指すかわ人それぞれとなりますので何とも言えませんが、状況に流される側の人間に立つか状況を作り上げる側の人間になるかはきちんと決めて日々生活をすると精神衛生上宜しいのではないかなと思います。
もちろん、僕は後者の状況を作る側の人間になりたいし、その為に独立しているわけなので色々と動かないといけないですね。
今回はここまでです。
最後まで読んで頂いてありがとうございました。
改めて実感したインフラ構築の難しさ
自分のPC内で同じ事できないか今環境構築している際に気づいた事について、railsなどのようなフレームワークを使った開発は大分効率的である事は確かではあります。
昨日の記事にした、ズルいデザインテクニックにしたって、railsの環境についてきちんと構築経験があれば、逆にCSSなどのデザインに対する知識や経験を軽くする事が出来ますので、何かアップデートをする際に変更しなくては行けない部分を簡単にできますからね。
ただし、これは「環境構築」が出来る事前提のお話だと言う事に作業しながら気づきました。
昨日の記事をみて自分でもやってみようと思って色々操作しているのですが、中々僕の環境にマッチした状況にする事に出来ない状態でいます。
複数のプログラムのバージョンを合わせる必要があるのですが、一番キツいなと感じるのが下記3者のバージョン合わせだと感じます。
この3者の共存関係が上手くいかないと折角のコードが動かない状態になってしまうので、なんとか簡単に管理出来る方法を探さないといけないです。
環境設定だけで相当時間を浪費します。
こうなってくると、実際にコードを書く時間よりも環境を如何に素早く作るかというところにスポットが当たりそうです。
実際にどういったロジックで動くのかだけ明確であれば、開発そのものはそんなに難しくないのでは無いかと考えています。
これに対してもう一つの道筋としては、自分でフレームワークを作ってしまうというのもありますが、開発能力ある人であればこっちの方が早いかもしれません。
依存関係は自分で作っているので理解が早くすぐ準備できますからね。
これやって成功している人達はrails作った37signalsやPaul Grahamとかでしょうか。
他にもいると思いますが、インフラの根っこの部分を押さえ込んでいると自分のプログラムを開発しやすいですからね。
あとは、僕がその方向性の方がワクワクするというところでしょうか。
今回はここまでです。
最後まで読んで頂いてありがとうございました。
railsの問題点(インフラエンジニアが必要な理由かも)
自分のPC内で同じ事できないか今環境構築している際に気づいた事について、railsなどのようなフレームワークを使った開発は大分効率的である事は確かではあります。
昨日の記事にした、ズルいデザインテクニックにしたって、railsの環境についてきちんと構築経験があれば、逆にCSSなどのデザインに対する知識や経験を軽くする事が出来ますので、何かアップデートをする際に変更しなくては行けない部分を簡単にできますからね。
ただし、これは「環境構築」が出来る事前提のお話だと言う事に作業しながら気づきました。
昨日の記事をみて自分でもやってみようと思って色々操作しているのですが、中々僕の環境にマッチした状況にする事に出来ない状態でいます。
複数のプログラムのバージョンを合わせる必要があるのですが、一番キツいなと感じるのが下記3者のバージョン合わせだと感じます。
この3者の共存関係が上手くいかないと折角のコードが動かない状態になってしまうので、なんとか簡単に管理出来る方法を探さないといけないです。
環境設定だけで相当時間を浪費します。
こうなってくると、実際にコードを書く時間よりも環境を如何に素早く作るかというところにスポットが当たりそうです。
実際にどういったロジックで動くのかだけ明確であれば、開発そのものはそんなに難しくないのでは無いかと考えています。
これに対してもう一つの道筋としては、自分でフレームワークを作ってしまうというのもありますが、開発能力ある人であればこっちの方が早いかもしれません。
依存関係は自分で作っているので理解が早くすぐ準備できますからね。
これやって成功している人達はrails作った37signalsやPaul Grahamとかでしょうか。
他にもいると思いますが、インフラの根っこの部分を押さえ込んでいると自分のプログラムを開発しやすいですからね。
あとは、僕がその方向性の方がワクワクするというところでしょうか。
今回はここまでです。
最後まで読んで頂いてありがとうございました。
Rubyistはズルい(かもしれない)
先週、仲間内でアメブロのカスタマイズについて講義をしていたのですが、僕の伝え方も考えなければいけないのですが、自分が思っている以上にCSSやhtmlって初心者の方にとって難しいと感じている事を知りました。
僕の場合、CSSとかHTMLを読めないのは単純に読む気が起きないという理由ですが、知らない人にとっては本当に困難だったんだと先週実感しました。
とりあえず、アメブロのCSSはわりとコメントは多い方なので親切だとは思うので、次回機会があればもう少しちっちゃい所からやった方が良いのかと感じます。
とりあえず、テスト用のブログ一つ用意して書いている所を弄れば、勉強できるかな。
下の見出しのようなCSSのみで描画するコードとかは思いつくのは結構面倒ではありますが、ネットに転がっているソースをペタって貼付けてしまえば、簡単に作れるのでそういった小技を教える方が良さそうですね。
見出し
まぁ、今までインフラばかり弄ってきてweb系の技術にも最近目を向けていますが、思った以上に簡素化されている事に驚きを隠せません。
railsでシンプルなブログシステムを構築するのなんて簡単ですからね。
ズルいデザインテクニック
https://speakerdeck.com/ken_c_lo/zurui-design
いや、これは非エンジニアの人には面白さはさっぱりでしょうが、これだけのコードでこんなけズルい事が出来るのだから結構十分じゃないかなと思ってしまいます。
なにより、ワクワクしますからね。
いやー、本当にこういうの見ると楽しいですね。
自分も試したり、何か作ってみたいと思わずにはいられないです。
今、SNSっぽいパッケージを考えているので、それが出来たら公開したいのですが、もう少しかかりそうですね。
やる事は分かったので後は、ユーザから聞いた欲しそうな機能をどうやってまとめるかが鍵だと感じます。
なんでも良いけど、Rubyistはズルいですねこんなに面白い事をやっているのだから、いい加減使いもしない要件定義とかを提示する業務から足を洗う為に日々努力しなくてはいけませんね。
エンジニアやってて一番楽しいのはシステムを動かす事なんだからそこに直接関わる仕事の仕方をしていかないといけないですね。
今回はココまでです。
最後まで読んで頂いてありがとうございました。
Macのショートカットについて
そういえば、身近な人でMacを購入している人達が増えてきたので少しだけ、知っておいた方が良い事を書いてみます。
windowsと操作は確かに変わるので、面食らいますがキーボードで何が操作出来るかという所は押さえておいた方が良いのかなと思います。
基本的に、WindowsでCtrlキーで操作している内容はCommandキーに置き換わります。
上がwindowsでのショートカットキー、下がMacでのショートカットキー
コピー
Ctrl + c
Commandキー + c
ペースト
Ctrl + v
Commandキー + v
カット
Ctrl + x
Commandキー + x
文全体の選択
Ctrl + A
Commandキー + A
ウィンドウを閉じる
Ctrl + w
Commandキー + w
アプリケーションを閉じる
Ctrl + q
Commandキー + q
一つ前の動作に戻す
Ctrl + z
Commandキー + z
ファイルを保存
Ctrl + s
Commandキー + s
一つ前の動作に戻す
Ctrl + z
Commandキー + z
大体主要なものはこんな所でしょうか。
大体はwindowsにあるコマンドはMacにもあったりします。
ルールとしては上のような感じです。
次にWIndowsであったかうる覚えなのですが、Mac利用する時に覚えておいた方が良いショートカットキー
Macのショートカットキー続き
開いているウィンドウの一番上に移動
Commandキー + ↑
開いているウィンドウの一番下に移動
Commandキー + ↓
カーソルがある文章の最後尾に移動
Commandキー + →
カーソルがある文章の文頭に移動
Commandキー + ←
開いているブラウザのタブ移動 左
Commandキー + {
開いているブラウザのタブ移動 右
Commandキー + }
その他にも色々なショートカットキーがあります。
こういったショートカットキーの情報は実は上部のメニューを見ると載っているので、使いたい操作がある場合は参照する事をお勧めします。
今回はココまでです。
最後まで読んで頂いてありがとうございました。
IT剣士流エンジニアリングのすすめ 使い回ししよう。
昔の技術は今では通用しないかというと、そうでも無かったりします。
特にインフラ側はシェル組めれば結構楽が出来ますね。
今僕たちのやっている開発手法の基礎とか言語も20年以上前のものからバージョンアップさせて使い続けているものが多かったりしますからね。
サーバ用のプログラムだとsendmail、bind、apacheなどどれも10年以上たっても使われていますし、色々と新しい技術の話題に事欠かないので、見失いがちですが昔っからある考え方を使い回しが出来るものもあります。
なので、古い話をしていてもやりようによっては、今新しく出来ているプログラムと同じ仕組みをシェルだけで達成する事もできますからね。
例えば、プログラムやシステム側に何か発生した場合に特定の場所にログとして保管するように基本的になっています。
そのログの文字列から特定の文字が入っている行があれば、決められた処理をするという事は昔からできるので重宝しています。
結構古い時代だとsedとawkが有名どころでしょうか、さすがに僕もあまり使えませんがこれでシェルを組むと特定の文字だけ変更したり書き換えたりする事が簡単に行えます。
本当に良く利用するコマンドは結構決められていて、そのコマンドを覚えておけば結構色々なサーバ作業が自動化出来てしまったりするのですね。
あと、テキストで読める辞書ファイルがあれば、クロスワードパズルの答えを導きだすようなシェルもかけたりするのですね。
そういった単純作業を積み重ねて複雑な事を達成したりしています。
ここで、大切なのは「データの流れ」を把握する事だと思います。
言語はどうでもいいのですが、したい事を単純化してその構造がどうなっているのか?何処と繋がれば良いいかを意識します。
コンピューターが出来る事は簡単な演算です。
ただ、その単純な計算を異常な速度で実行できるからまるで魔法のような事が出来てしまうのですね。
ロジックを考える時は、この流れを意識して僕は考えています。
本当に欲しいものは何処に行くべきか押さえておかないと僕にとって便利でないものが出来上がってしまいますからね。
あとは、それが何度も使い回せるような形に作る事が出来れば、自分の作業がぐっと楽になります。
これを積み重ねていくと、インフラの人は普通の人では考えられないような効率をたたきだす事が出来るのですね。
なんでもそうですが積み重ねというのは本当に大事ですね。
今回はここまでです。
最後まで読んで頂いてありがとうございました。
先輩エンジニアの昔話を聞いて
昨日は仲間のあつまりで飲み会があったのですが、とても面白い話が出来て良かったです。
僕は新しい技術も好きですが、エンジニアの昔ばなしも結構好きだったりします。
例えばプログラムを紙のテープに点字みたいに打ち込みそれをコンピューターに読み込ませるという仕事があったそうです。
それは僕は生まれていたのかもよく分からない時代なんですが、どうやらそのテープっというのは相当長いようで(3mとか5mって聞いた事あります。)
まぁ、ただの紙の束ですからね落とすと大変な事になるようです。
なので、同僚でテープをこぼしたら相当恨まれる事があったそうです。
あと、読み込む時も自動化が出来ていない時があって、手でゆっくり読み込ませたという話も聞いた事があります。
昔のプログラムは今程複雑では無かったとはいえ。
そんな手作業で長時間読ませる仕事っていうのは精神的にしんどいんだろうなと思います。
こういった話を先輩エンジニアの方から聞いたりするのは個人的にすきだったりします。
そういった話を聞いていると本当に仕事が好きでやっていて、大変だった記憶も良い思い出になっているように感じます。
巷では好きな事を仕事にしたいという方が増えていますが、実際好きかどうかってあまり関係ないのではないかなと感じます。
最初はダメでもやっていくうちにのめり込む事って案外ありわがままばかり言うのでは無くちゃんと実績を積み上げて成長していってもらえたらなと思います。
チープな事を繰り返していてもハリボテの空虚なおじさんが出来上がるだけですからね。
物事って何処でハマるか分からないと思うので、新しい物事に挑戦出来る場があるなら積極的にやってみる事にしています。
正直、僕は1対nで話すより1対1で話す方が好きだからあまり多人数が一緒にいる場というのは苦手ではありますが、最近は集まりがあれば参加するようにし手伝える事は率先して手伝うようにしています。
まぁ、上手くいくかはその時々で変わるはずです。
まずは、実行して結果を見直しまたチャレンジする。
これを繰り返してやっていきたいなと思います。
今回はココまでです。
最後まで読んで頂いてありがとうございました。
IT剣士流エンジニアリングのすすめ エンジニアの供給が足りていない理由
前回の続きです。
供給が足りていない理由について、前回の話ではそもそも教育しているところが少ないというところを書かせて頂きました。
プログラムについては、教えているところっていうのは多いのですが、インフラは趣味の延長線場にあるという状況ですね。
さらに、就職した後に、それを体系だてて教える土壌のある会社が圧倒的に少ないというのもあります。
多分OJTでインフラをきちんと教えているところは数える程しか無いですね。
ほぼ、インフラに限っては独学が必須になってくるように感じます。
最近AWSがありますからね。更にこの傾向は加速しそうです。
実際に、僕自身も独学で学んでいましたし、会社によってあ口伝がほとんどで「身体で覚えろ!」っていう理論と経験が重視される仕事だと思います。
あとは、探究心が強い方が多い傾向にあるのかなと思います。
同業者にあうと、何かしら自宅でネットワークやサーバ、システム構築を趣味で行い運用しているパターンが多いですね。
わりと皆コンピューター好きなんですよね。
仕事から帰ってきて「はぁー疲れたぁ、じゃあちょっとサーバ弄るか」という流れでついついサーバを触ってしまう人もわりといますからね。
こんな四六時中、サーバ触っているような奴らを相手に、普通に職業としてやっているヤツが敵うわけがありません。
しかも、大体必要とされるのはこの前者の好きで仕方なくてサーバ触っている奴らなんですね。
ただ、ここにミスマッチがあって、この好きでやっている奴らは多くの場合企業のシステムを嫌っている傾向があります。
というか僕はそうです(苦笑)
これは、規約ありきや外的要因でのシステム導入ばかりをすすめて、本当にやりたいことってなんなのという事を聞くととたんにモゴモゴしてしまうようなインフラを作っている会社が多いんですね。
このモゴモゴの部分は色々あるので割愛しますが、理論的なようでいて破綻している事を言っている場合があります。
まぁ、インフラ設計に関しては最初間違えると後は救いが無いので、仕方ないっちゃ仕方ないんですね。
何となく論理立てておかないと、全部壊すしか方法が無くなってしまうから。
その破綻しているモノを正しいモノにするには一番早い方法が「一から作り直す」という方法になります。
ツギハギだらけのシステムがまともに稼働し続ける事って結構難しいのですよ。
それやれる人って然う然う見つかりません。
企業は安くてレベルが高い人を探しますが、そんな都合の良い人はもっと面白い現場に行っているのだからこのミスマッチの溝は中々埋まりませんね。
これも本当に必要な教育を疎かにしてきた企業や社会のツケなのかもしれませんね。
今回はココまでです。
最後まで読んで頂いてありがとうございます。