コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

汎用化処理に対して良いアプローチを考えたい

雑記

雑記です。

Railsをやっていると『DRYじゃない』とか『DRYにしよう』みたいのでいろいろ処理をまとめることが多いと思います。その結果、親しいカテゴリの処理が一つにまとまることが多いです。

ただ割と起こりがちな現象として

  1. 似たような処理だが細部が違うので吸収できるように汎用化する
  2. 汎用化するとINPUTの多様性が上がってくる
  3. 例外ケースを補足するguard説が増えるなど、パターン対応に追われ処理が複雑化する

みたいな現象が発生します。

これに対しては以下の問いかけをするとバラせるかなと思ってて

  • その処理はいろいろなことをやりすぎではないか
  • その処理はもう少し分解できるのではないか
  • その処理で吸収しようとしていることは本当に今必要なのか

みたいなことでいい感じにばらせるのではないかと思ってます（よくある言葉だとYAGNIと単一責任原則みたいな感じ）

割と良かれと思って作った汎用化が闇を生むので、そこらへん作っちゃう感じのながれになったら、うまくバラすための紐解き方とか考えたいなと思う今日このごろでした。

関連リンク

やるべきことが進まないので1回休み

日記

日記です。

割とスケジュールに余裕が見えたので、ちゃんとブログを書こうとか、チーム内のレビューをしっかりやろうとか、みんながぼんやりと抱えている課題や決めたほうがいいことを考えていかなきゃなと思ってたらまた実務時間がなくなってスケジュールがカツカツになるやつ。

このためにカイゼンジャーニー読もう読もうとおもって読めていないので早く読もう。。

本当に10分でアーキテクチャの歴史がざらっと学べるスライド『10分で振り返るソフトウェアアーキテクチャの歴史2017』

スライド・記事回顧録

最近記事になるような学びがないので、スライド回顧録です。

speakerdeck.com

過去にMVC,MVP,MVVMの比較記事書いてるんですが、その数カ月後に出てきたスライド。凄まじい。

注意書きにiOSエンジニア向けと書いてあるが、iOSのエンジニア以外にも全然説明ができる資料となっていると個人的には思ってます。

この資料のとても良いポイントは

  • GUI Architectures
  • Whole Application Architecture

という形でよくごっちゃで扱われがちなCleanArchitectureとMV*系の説明をちゃんと分類しているところ。そして基本的に論文などを出典としているところ。

自分もアーキテクチャ系の資料をまとめたいなと思ってるので、こういう出典元をちゃんとたどるべきだなと思ったし、やりたいと感じたのでした。

RubyのBase64.encode64はエンコード後文字列が60文字以上になると改行コードが入る

Tips Ruby

なんだそのRFC仕様…と思ったのでメモ

環境

$ ruby -v
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin16]

概要

与えられたデータを Base64 エンコードした文字列を返します。 このメソッドは [RFC2045] に対応しています。 エンコード後の文字で 60 文字ごとに改行を追加します。

module function Base64.#encode64 (Ruby 2.5.0)

ということでRFC2045の仕様に基づいて60文字ごとに改行が入る

例

sample.rbとして以下のようなコードを書いて…

require 'base64'

str = "あいうえおかきくけこさしすせそたちつてと"
p Base64.encode64(str)

実行すると

$ ruby sample.rb 
"44GC44GE44GG44GI44GK44GL44GN44GP44GR44GT44GV44GX44GZ44Gb44Gd\n44Gf44Gh44Gk44Gm44Go\n"

謎の改行コードが入る

なお、入ってほしくない場合は Base64.strict_encode64() を利用すると良い。

例としてsample2.rbとして以下のようなコードを書いて…

require 'base64'

str = "あいうえおかきくけこさしすせそたちつてと"
p Base64.strict_encode64(str)

実行すると

$ ruby sample2.rb 
"44GC44GE44GG44GI44GK44GL44GN44GP44GR44GT44GV44GX44GZ44Gb44Gd44Gf44Gh44Gk44Gm44Go"

改行コードが消えた

参考リンク

良いコードレビューの回しかたを考えるときに一度読みたいスライド、『デキるプログラマだけが知っているコードレビュー7つの秘訣』

雑記 スライド・記事回顧録

スライド回顧録です。

www.slideshare.net

ヤバいコードとはなにか、それを生み出さないためのレビューとはどうあるべきか、それを言語化するときに手助けになるのがこのスライドです。

スライド内で大きく取り上げられているのは7つ

  • レビューの観点を明確にすること
  • 我が身に返ることを恐れずに指摘すること
  • なぜ悪いコードなんかを理論的に説明すること
  • 良いコードについて共通認識をもつこと
  • 小さい単位でレビューを繰り返すこと
  • 指摘は素直な気持ちで受け入れること
  • 指摘は人格否定ではないことを理解すること

これは今現在に至る自分のコードレビューの指針にもなっていて、『雑な指摘をしてもただただ反感を買うだけなのでちゃんと直す意味を持って指摘する』とか『PullRequestの単位はなるべく小さくするようにする』とかそういう考えのもとになってきました。

なかでも棚上げにしろという部分は一番大事で、結構これができずに表面的なレビューに終始してしまいがちなので、非コードレビュー文化圏から来たひとにはそれを布教するのを割と大切にしてたりします。

コードレビューのルールなどを考える機会があったら、読んでみるといいのではないでしょうか。

関連リンク

『GDG DevFest 2018 Tokyo』に行ってきたよメモ

行ってきたメモ

『GDG DevFest 2018 Tokyo』に行ってきました。自分の見てきたセッションをつらつらとメモ。

各発表の感想

実践！！Web パフォーマンス改善！

スライドは非公開ということで、スライド内で紹介されたTipsをツイートで紹介されてたのでそちらを紹介

※このツイートにいろいろぶら下がってます

感想

  • WebPerformanceを最適化するためのTips紹介
  • 関連ツイートにも紹介されているがLightHouseでの計測がはじめ
  • あとはJSを分割して軽くすることや画像の軽量化など、よく話にはあがるものそのままライブコーディングでわかりやすく紹介してくれてわかりやすいものだった。
  • PWAでも軽快なWebサイトづくりは重要になってくるので、かなり良い知見となった

関連リンク

FireStoreDetabase Design

感想

  • 全く普段RealTimeDB使ってないから考え方が全然違ってなるほどと思うばかり
  • セキュリティ的な縛りに対して、データの設計でカバーするというのは結構斬新な気持ち

関連リンク

AndroidX時代のHello World

感想

  • 先日のIOのJetpack含めたおさらい的トピックス
  • Jetpack出たよぐらいしか知らなかったので、割と非同期処理とかそういうものにも新しい取り組みがあることが知れてよかった
  • 久しくAndroid書いてないのでこういう最新動向系はすごい助かる

関連リンク

Cloud Kata

感想

  • GCPにおける構成デザインパターン、Kata（型）の説明。ジャパニーズカラテ。
  • 普段はAWSで仕事しているので、GCPならではーな感じので組み合わせパターンも聞けてよかった
  • PERSISTENT DISKは分散DBだからSnapShotも実データコピーじゃないから高速なんですよーみたいな話はGCPならでは感が多分にあった

Introduction Polymer 3.0

(まだなかったので見かけたら貼ります)

感想

  • WebComponentsの動向と直近出たPolymer3.0関連の話
  • 最近CSSに苦悩しているのでWebCompornentsに関してのトレンドを知れた
  • 事例も交えてだったが単発サイトとかであれば結構いろいろ使えるのでよさそう
  • Reactとの親和性低そうなのが気にはなった。。

関連リンク

TypeScript導入で得られる、変えていく勇気

感想

  • TypeScriptとはどういう時流の中できたものなのか、また入れることによるメリットは何なのかという説明
  • どうせコンパイルが必要ならちゃんと型チェックでコンパイルエラーで落とそうぜという考え方
  • 型付言語世界観のベストプラクティスを水平移動できるのやっぱり強いなという感じがした。
  • やっぱいいですよね値オブジェクト、冗長にはなるけど積極的に使いたいものです。。

関連リンク

Firebase Realtime Database in Production

感想

  • チャットシステムの事例、すごい重厚な構成だなとは思ったが、ビジネス要件が変わってそうなってしまった感がにじみ出てる発表だった。
  • FireStoreの事例でもみたが、NoSQL+RealtimeDBは探すことが不得手なのでそこをサポートしてあげる必要があるというのをひしひしと感じた
  • クライアント側にWriteを許すとスキーマ管理の難度があがるのも対応策ないのかな…という感じだった

関連リンク

全体を通しての感想

  • 最近のお仕事がバックエンドアプリとあんまりボリュームがないフロント、ときどきクラウドインフラなのでそこらへんを中心に聞いた。
  • Firebaseいいなーと思う半面まだ安定運用できてないという話も聞くので堅さが求められる案件だと使いにくいなという印象
  • ホントはGoとかFlutterのセッションも聞きたかったけどだいたい聞きたいのはかぶってたので残念。。
  • しかし今日はカンファレンス同時多発だったな…

他の方の感想など

ドメイン駆動設計にふれる前に読みたいスライド『How to Apply DDD to Android Application Development』

スライド・記事回顧録

スライド回顧録です。

y-anz-m.blogspot.com

あんざいゆきさんがDroidKaigi2017で話した、DDDのエッセンスをAndroid開発に持ってくるための話。

割と勘違いされやすいDDDの用語に対しての話や、Androidのコードを交えた話を実際に話すときのカンペ付きで公開されています。

このスライドを読むことで

  • 戦術的なDDD（実際のコードに使えるDDDの考え方）
  • 戦略的なDDD（開発ではなくプロジェクトのような大きな単位のDDDの考え方）

というのがあることを理解することができます。（かつ戦術的な部分はどちらかというとオブジェクト指向の文脈が多いことがわかる）

ということでAndroidと銘打っておりますが、どの言語の人でもDDDを理解する上では読んでみると良いスライドかと思います。