IT界隈じゃもはやSlackがデファクトスタンダードになりつつあるけど、 残念ながらうちの会社が使っているのはChatwork。
多機能なのは良いんだけどMarkdownには対応してないし、 APIはいつまで経ってもプレビュー版のままだし、 そのAPIもイマイチ機能が足りない感じ。
なんというか全体的にエンジニアフレンドリーじゃない感じがするんだけれど、 これって日本の企業では決済権を握ってるのが事務方が多いことに最適化した結果なんだろうなーなんて 競合Slackとの差異に思いを馳せたりする。
そんな愚痴はさておき、今回はGo言語の勉強がてら作ってみたchwkコマンドについての紹介。
続きを読む最近同僚と呑む機会があって、年齢がらどうしても「いかにエンジニアとして生きていくか」みたいなところの話題になったりする。
その中でこんな話をした。
日々新しいフレームワークやツールは出てくるし、 ミドルウェアや言語やアーキテクチャの流行も移り変わる。
もちろん何でも新しいものに乗れば良いというわけではないが、 ある程度世間の潮流を押さえるのもエンジニアとしては必要な態度だろう。
ここ数年僕がモチベーションを保つためにやっているのは、 「何年かして転職する際にネタになる」という発想。
そうやって考えることで「今は楽だけど先がない」みたいなものを作り変える切っ掛けにもなるし、 自分がどういう方向に進みたいかという軸で学ぶべきものの取捨選択にもなる。
ある程度責任ある仕事を任されるようになってくると、 何かと技術的な選択を迫られることがある。
そんな時に考えるのが「転職の面接でその選択を論理的に説明できるか」ということ。
そうやって考えることにより「今やる分には楽だから」とか「社内政治的に」とかいった視点から離れ、 選択肢を客観的に見つめ直すことができる。
こんな感じのことを考えて、僕はここ数年仕事に取り組むようにしている。
ことにウェブやソシャゲの業界は企業の栄枯盛衰が激しく、 今のところ自社の状況が悪くないからといって安心できるものではない。
実際問題として転職というオプションは常に持ち続けるべきだと思うし、 そうでなくても自身の市場的な価値をいかに高めるかということは意識に置いておくべきだろう。
そうやって技術的な向上心を維持することが、 プロダクトの価値にも繋がっていくのではないかと思っている。
↑最近読んでいる。 自己啓発系なものかと思いきや具体的な含蓄があったりしてなかなか面白い。
貼ろうとして気づいたんだけど、これ色々シリーズ出てたのね。
あと書きどころに迷ってるうちに書き忘れてたんだけど、 過度に会社と自分とを一体化しないことで精神的な安定を保つって意味もあるなーなんて思ってる。
新卒の頃、就活の面接で「オブジェクト指向を理解していますか？」という質問をされたことがあった。
その時は確か「一応、一通り教わった程度には・・・」的な回答をしたような気がする。
どういうものかという概念は分かっていたものの、それを十分に活用できるレベルかというと怪しかった気がする。
（にしても、今にして思えば随分と面接下手だったなぁ）
それでは今なら十分に使いこなせるかと問われると、正直なところ、恥ずかしながらそれほど自信は持てていない。
実際、現場に出てみると不適切なオブジェクト指向「もどき」による混沌としたコードを見かけることも少なくないし、 自分だってそれを上手く改善していけてたかというと怪しい面もある。
そんなわけで、一度基礎に立ち返ろうということで『オブジェクト指向でなぜつくるのか』を読んでみた。
このまま忘れてしまうのも勿体無いので記録に残しておこうかなと。
技術系のネタは最近は別ブログの方でやってたけど、具体的なコードなんかは無いので今回はこっちで。
思い出した・思いついたら随時追記していく予定。
フィーチャーフォンの時代からのサービスで、 無茶な拡張や教育不足や委託によるアレな開発状況によって、 コードも環境も技術的負債が山盛りの状態だった。
幸いにしてサーバを移設する機会に恵まれたので、 状況を改善するべく検討を進めた。
様々な部分において、環境ごとの差異が看過できない状態になっていた。
サーバによってインストールされているランタイムやモジュールのバージョンが異なることもあれば、 パスが異なることをコードにベタに記述してバージョン管理しないことにより対処している部分があったり、 そもそも環境によって同名のスクリプトの内容が書き換えられていたり。
バージョン管理ももはや正しく機能していなくて、必要なファイルだけ明示的に本番環境に上げるような綱渡りな運用になっていた。
おそらくリアルタイムでは、「急いで対応しなきゃいけないから仕方ない、後でちゃんと揃えよう」とかなんとか考えていたのかもしれないが、 往々にしてそういう意識は長続きしないもの。
結果として、どのサーバ環境での挙動が「正」なのかも分からない状態となっていた。
こうなってくると新たに環境を構築するのも困難だし、 リリース前の検証作業も不確実なものとなってしまう。
もちろんそれぞれ個別には対処法はあるにはあるんだけど、 それを全て長期的に完全に徹底していくことは困難なように思えた。
個人的には「気をつければ」とか「ちゃんと確認すれば」とかいった前提で成り立っているような運用というのは即ち無用にリソースを消費している状態なので、 今問題ないからといって看過すべきではなくすぐにでも改善すべきだと思っている。
そういったストレスを抱えながら開発運用していくよりも、 Dockerを用いた「可搬性ある形」を前提として使い方を習得してもらうほうが現実的で長期的なメリットもあると考え導入に踏み切ることにした。
（とはいえ、僕が使いたかったから理由を揃えて押し切ったという側面はちょっとある。 退社時期的にちょっと申し訳ない気もしている。）
転職活動でもお世話になったCodeIQで↓のような問題があったので回答を出したところ、 レビュー会への招待が来ていたので行ってみた！
出題はじゃんけんを行うプログラムをリファクタリングするという問題。
「標準入力として与えられた文字列を2人分のじゃんけんの手として解釈して勝敗を標準出力する」というもの。
元はnode.jsだったのだが、僕はjsが不慣れだったりもするのでperlで再現。
sub func02 { my ( $a, $b ) = @_; if ( $a eq 'g' ) { if ( $b eq 'c' ) { print "win"; } elsif ( $b eq 'p' ) { print "lose"; } else { print "draw"; } } if ( $a eq 'c' ) { if ( $b eq 'p' ) { print "win"; } elsif ( $b eq 'g' ) { print "lose"; } else { print "draw"; } } if ( $a eq 'p' ) { if ( $b eq 'g' ) { print "win"; } elsif ( $b eq 'c' ) { print "lose"; } else { print "draw"; } } } sub func01 { my $line = shift; my ( $a, $b ) = split / /, $line; &func02( $a, $b ); } my $line = <>; chomp $line; &func01($line);
すごーくベタな実装。
コード自体は目的どおり正しく動作するが・・・
続きを読むTwitterBootstrapみたいなOSSプロジェクトなんかでよく見かける「xxxx.github.io」というドメインのあれ。
技術系のブログなんかで「Githubでスタティックなページなら無料で公開できる」みたいな話もちょいちょい見かけていて気にはなっていたのだが、 特に調べる切っ掛けもなくて具体的な方法を知らなかったんだよな。
今回ちょっと使ってみたい用件（後述する）もあったので調べてみた。
そもそもこれはGitHub Pagesというサービスらしい。
使い方は実に簡単。
GitHub上で[自分のアカウント名].github.ioというリポジトリを作成し、
そこにファイルを上げれば完了。
※既に作ったあとにスクショ撮ったんでエラー表示になってる
続きを読む業務じゃ運用っぽいことやってるくせにCI（継続的インテグレーション）まわりを全然カバーできてないのはそろそろ恥ずかしいので、 自宅サーバで色々動かして勉強してみようという試み。
（以前に軽くJenkinsはさわったことあるけど、スペックとかの問題でまともには運用できてなかったんだよな・・・）
今回導入してみたのはGitLab CI。
会社でも自宅でもプライベートリポジトリとして利用しているGitLabなのだが、 都合が良いことに８系からはCI機能が統合されたらしい。
GitLabのCI機能を使うためにはあとはRunnerというビルド等を行う側を用意さえすればよいのだが、 こちらも幸いなことに本体同様にDockerイメージがある。
そんなわけで、先日のGitLab本体に加えてGitLab CIもDockerで動かしてみることにした。
続きを読む