2019/01/08 気になる記事まとめ
仕事も始まり、年末年始休暇からパキッとした仕事モードに戻す時期がやってまいりました。 残念ながら私はもどっておりません_(:3」∠)_
Githubさん太っ腹
この日一番のニュースだったんじゃないでしょうか。弊社でも話題になってました。 私はgithub課金者だったんですが、3人のコラボレータまで無料でprivate repository作れるなら、課金しなくてもよくなりました(｀･ω･´)
githubは今後より企業向けにシフトしていくんでしょうかね。直近だとActions
がパブリックベータやっていたりと、企業向けや有料ユーザーに対する機能追加で利益を得ていきそうな雰囲気ありますね。
scaffdogよさそう
ひと目見た時は、Markdownで記述していくの違和感あったんですが、宣言部とテンプレート部を1ファイルに収めようとすれば、こうせざるをえないんだろうなぁ、と感じました。 Rubyだとymlとerbを使ってgenerateするみたいなことをやってましたが、それに似ている印象。 新規でフロントやる機会があれば採用してみるのもおもしろそうですね(｀･ω･´)
gitの使い方がわかる良記事
普段なんとなく使っていますが、やはり使うのであれば理屈を知りたいところ。 細かな説明も妥協なくまとめられており、めちゃくちゃ理解しやすいです。初学者に理屈を覚えてもらうには大変よい記事ですね(｀･ω･´)
作業メモをどう管理するか
ソフトウェアエンジニアってかなり調べ物が多い職業だと思うんですよ。
APIドキュメント読んだり、実際に手を動かしたり等。調べたその時は頭の中に入っているんですが、1週間もすればすっかり揮発してしまうんですよねぇ...
この手の調査や作業メモ関連、皆様どのように管理しているでしょうか？
私個人としては、いろいろと試した結果、kibelaというサービスを使うことで決着してます。
kibelaについては、以前書いたこの記事で触れているので見てもらうとして、
以前は、テキストエディタでローカル管理、Simplenoteでオンライン管理と試してきました。ただ、それぞれに課題があり、なかなかうまく運用できてなかったんですよ(´・ω・`)
テキストエディタ運用時代
最初に考える方法の一つ。ただ、やはりというか当たり前な課題がありまして、
- オフライン管理なので、他の環境に行ったときに見れない
という点が辛く(´・ω・`)
会社で調べた続きを家で調べることも多くあり、いつでもアクセスできるところにあることが必要なんですよね。これではいつでもどこでも調べた結果を記録できない。git管理という手もあるんですが、外出中にiPhoneでgit管理、多分脱獄すればできなくはないんですが事前準備が面倒です。
結局これだけでは期待していることが満たせず、別の方法を模索し始めます。
Simplenote運用時代
次に手を出していたのが、Simplenoteですね。
読書メモやブログの下書きにも使っているんですが、よくあるオンラインメモサービスです。気軽に立ち上げて書け、検索もそこそこできるやつでした。Markdownも使えるので書き感も悪くない。
しばらくSimplenoteで運用して事足りていたんですが、使い込んでいくにつれちょっと使いにくいところが出てきました(´・ω・`)
作業メモとは、その時何を考えて調べたかをまとめたものです。つまり時系列の情報も必要になってくる。Simplenoteだと工夫をしないとその運用ができないんですよね。文書の中に日時を書き込むという人力運用でしたが。
ただねぇ、やはり都度都度日時を入力するのがめんどい_(:3」∠)_ 可能であればそこまで自動でやってほしいなぁ、と思ってました。
kibela運用時代
そして今に至るkibela。
このサービス、作ったページにに対してコメントを書けます。時系列の管理にこのコメントを使うわけですね。コメント入れて投稿すれば勝手に時間が記録される。Simplenoteでの課題が見事に解決されています。
調査している事項ごとにページを作り、調査した結果を都度コメントに記録していく。コメント部分でもMarkdownが使えるので調べたことをガシガシと書いていく。現状はこの運用が一番ラクにいけてますね(｀･ω･´)
こんな感じになります。
後から見直した後でも、何考えてたか追えることで思い出しやすくなる効果もあります。
今後生きていけるソフトウェアエンジニアについて考えた
あっという間に年明けし、親戚周りや宴会で疲労気味です、こんばんわ_(:3」∠)_ 関係者各位におかれましては、2019年も引き続き、宜しくおねがいします。
さて、タイトルが若干主語大きめなのですが、ここ数年エンジニアの需要に動きがあるのでは？と個人的に思っています。
従来どおり依頼された仕様書に沿って作っていくエンジニア、の募集よりビジネスとTechを回せるエンジニアの求人が(体感的に)増えてきていると感じました。去年の転職活動でもいろんな企業を見てきたんですが、SESを収益の柱としている企業以外では、ほぼ確実にビジネスにどういう貢献ができるか？といった軸での採用基準があるように思います。
ビジネスへどういう貢献ができるか？ソフトウェアエンジニアであれば、自身が持っている技術を駆使してビジネス価値を作っていけるか？に言い直されます。
ソフトウェアエンジニアの人材不足という声がよく聞きます。その一方で仕様を元に作るだけのエンジニアの数は十分だ、という声も聞きます。
転職市場においてビジネスを創発できるエンジニアの需要が大きいという感覚が正しいのであれば、つまりビジネスを成長できる人材であることが、今後生きていけるエンジニアとして必要とされている能力なのかもしれません。
と、親戚周りでお酒を頂いていたときにふと感じた、雑多な書き起こしでした。
2018/12/31 気になった記事まとめ
今年も後数分で終わります。年末最後のまとめです。 毎年このタイミングで体調不良なのなんででしょうね？ _(:3」∠)_
slackクローンのOSS
私個人の使い方だとまだフリーなSlackで問題ないので使う予定はないんですが、いざSlackで足りない場合に選択肢があるのはいいですな(｀･ω･´)
行きたかったけどタイミングが合わなかったJetBrain Night
こうして当時のセッション動画が公開されるのいいですね。タイムライン見ていた限りだと貴重が多くあったとのことなので、正月時間があいたら見ておきたいとおもいます。
本日は時間が取れなかったのでこんなところで。
来年も宜しくおねがいします。
2018/12/30 あと1日で今年が終わるので振り返ってみる
早いもので今年もあと1日です。ここ数年で一番動きがあった一年だったと思いますな(´・ω・`)日本の中のことでもそうですし、私個人のことでもそうです。
今年はいろいろと環境が変わったりする一年でした。4年務めた会社をやめたり、今までやったことないEC系の会社に転職したり。入社してすぐリプレース開発にJoinして炎上と戦ったりと、新鮮な経験ができました。
後は、まあ住宅ローン背負ってしまったり( ﾟдﾟ)数千万が一瞬で口座を移動するあのヤバさを実感するなど。今後どう生きていくべきか改めて考える時期に来たのだと感じてます。
話は変わるんですが、今月の頭くらいから毎日ブログを更新する日課を課してきました。これまで気が向いたときにしか書いてなかったんですが、今後の人生考える上でアウトプットすることに慣れる必要があるんじゃないか？と最近特に感じてたんですよね。
度々、「今度は頑張って更新していくぞ！」とやる気を出したのですが続かず。なんとかいい文章を書こうという気負いも合ったかと思います。(8月-10月あたりの迷走っぷりはそのせいもある)
継続する意志を持って、まずはやってみる。それだけで20日ほど継続できる事実があるわけでして、やはり『やってみる』ことは大事。この学びがあるだけでも、来年はより成長できる一年になるんじゃないかな？と思います。
来年は今年以上に結果を出す一年にしたいです(｀･ω･´) 会社以外の成果をきちっと出して、自分の武器としていく。来年はそれを目指して生きていこうと考えています。
どんな一年になったか、来年の今頃改めて振り返る際に、期待以上の一年になったと感じられれば最高ですね。
2018/12/29 気になった記事まとめ
今年はいろいろありましたが、無事に仕事納めを迎えましたね。来年もgdgdだらりと生きていきたいと思いますこんばんわ。
ブロックチェーンはオフチェーンじゃないとつらいぞよ(´・ω・`)
ブロックチェーンでのサービスの作り方の用語解説のようですね。
以前、有料の勉強会でSolidity使ってEthereumのコントラクト書いた事あるんですが、ブロックチェーンで保存される変数、そうでない変数みたいな使い分けが面倒だった記憶があります(´・ω・`)
記事でも触れられてますが、一度デプロイすると原則修正できないです。バグが有っても修正できない_(:3」∠)_
設計やテストをしっかりやって、完全な状態で出さないと行けないので、実際にやるときは注意する必要があります。開発者用のネットワークがあり、そこでお試しできるのが救いですかねー。
個人的に触ってて一番たいへんだったのは、トランザクションの完了が遅いところ。一般的なWEBアプリ的なものを全部ブロックチェーンでやろうとすると、まともに処理できないアプリが生まれてしまうので、本当にブロックチェーンを適用すべき場所を見極める必要があります。
いろいろと運用の癖や課題もあります。以下は結構参考になりそうです。
GraphQLでのアップロード
以前、諦めて普通にRestで処理するようにした記憶が(´・ω・`)
最近、弊社でもGraphQL採用のMicroservice増え始めたんですが、運良くReadしかないのあんまり困っていませんでした。ファイルアップロードするときの良い知見
そういえばあったよTracePoint
これまであまり使い方わからなくて触れてなかったんですが、ブレークポイントを気軽に貼るやりかたいいですね。
いちいちbinding.pry埋め込んでましたよ(´・ω・`) これがあれば動的に差し込めるので、「あ、ここブレークポイント貼って動かしたいな」と思ったときにさっと晴れると、いちいちコード書き直す必要もなく楽に調査できそうですね。
Transient Heapについては、ずいぶんピーキーだなぁという印象。
theap で一度に確保できる領域は 2KB に制限しています。このサイズに何か根拠があったわけではなく、当てずっぽうです。もしサイズを超える場合は、最初から malloc() して、theap を利用しないようにします。
Railsで普通に使っていると、2KB以内で収まるものってあんまりない気がします。それこそ使い捨ての変数くらいで、一番生成されるんじゃないかと思われるActiveRecordモデルのインスタンスだとほぼ確実に超えそうですし...
うまく付き合う方法を模索してきたいですね(｀･ω･´)
開発用DockerでのDBの初期設定について考える
最近、本腰入れて個人開発はじめました。 ちょっと今のブログが使い勝手よくないんで、CMS付きのブログサービスを作ろうかと(｀･ω･´)
さて、今の時代開発環境を構築するにはDockerという便利なものがあります。 諸々の初期設定が出来合いで用意されているので、開発着手までが以前より素早く行えるようになります。いい時代ですね。
さて、今回はCMS付きブログサービスをつくるのでDBは必須です。まあMysqlになりますかね。
もし需要あってサービスインする場合でも、即AWSAuroraに載せられるので楽に運用できますし。
さて、それでは開発を、といったところですが、Database作ったり、アクセスユーザー用のGrant発行したりといった細かな作業する必要あるんですよね(´・ω・`) 今回はDockerつかってScrap＆Buildが繰り返されるので、毎回この作業するの面倒です。
mysqlに関して言えば、公式イメージを使うことで、コンテナ側の/docker-entrypoint-initdb.d以下ファイルを読み込んで、初期設定できる機能があります。
https://hub.docker.com/_/mysql/
この説明の中に、Initializing a fresh instanceの項がありますが、そこに
When a container is started for the first time
とあり、containerの最初の起動時に一度だけ呼ばれるようです。実行できるのは
で、これを用いればDB作ってユーザー権限付与して、SQL dumpから初期データ作成等できますね(｀･ω･´)
実際に呼び出されるタイミングは、
で、この、docker-entrypoint.shはDockerfileの
mysql/Dockerfile at 696fc899126ae00771b5d87bdadae836e704ae7d · docker-library/mysql · GitHub
で呼ばれています。つまり、イメージをビルドしたタイミングで呼んでくれるので、containerの最初の起動時に一度だけの動きをしてくれるみたいですね。良く出来てて、とてもいい(｀･ω･´)
実はMongoDBも使おうと思って調べてたんですが、こちらにも同じような仕組みがあって、
https://hub.docker.com/_/mongo/
This variable allows you to specify the name of a database to be used for creation scripts in /docker-entrypoint-initdb.d/*.js (see Initializing a fresh instance below). MongoDB is fundamentally designed for "create on first use", so if you do not insert data with your JavaScript files, then no database is created.
こちらはjsで実装する形になりますが、同じように初期化処理が実現できるようです。
