管理ゼロで成果は上がる を読んだ
管理職=マネジメントとなりがちだけどこの本を読んで違うんだなぁと再確認した。
全体的に読んでて自分も管理職の存在に疑問符を持っている(が、一応現職管理職なんだけどw)ところに、少し光明が見えたが、うちだとどう当てはめられるんだろうなぁという疑問符も新しく出てきた。
作業ではなく、仕事をしてもらうことによりメンバー各自が考えて行動をするというのはすごい難しいんだろうなぁと思う。色々な会社はベクトルが広すぎてみんながバラバラになりやすいので、管理職というのが置かれていると思っている。なので、ベクトルを狭くすれば管理職をなくせるのではないか?と思うが、会社としてベクトルを狭くするというのは難しいんだと思う。
ただ、管理職をなくすというよりも、どのように気持ちよく働いてもらえるかという指針にはなったのかなぁと思う。例えば評価も今はevaluationになってるものをassessmentにしたり、期待値を合わせたり。
振り返りの方法もやったこと、わかったこと、次にやることもきちんと筋道立てて示されて自分の中できちんと言語ができておらず空白になってた部分を補ってくれた。
あと、管理よりも採用コストに割いているというのはすごいなーと思った。確かにそちらのほうが初期コストは高いかもしれないけどトータルコストは低い気はする。ただし、一人あたりのコストは高そうだ...それこそもっと採用にタッチする人を増やさねば。また、人を見極める4つの指針(Technique, Intelligence, Personality, Speed)がきちんと可視化されてるのはすごいと思った。
そういう意味で管理するのではなくメンバーのモチベーションなどをマネジメントしていくのは必要なんだろうと思う。
色々メモってるけどなんかうまく文章にまとめられないので気になった部分が会話できればいいと思う。結構自分は部署をまたいでガンガン行くタイプ(というか、全部知りたい)なので、その動き方で間違ってない、正しいんだ。と勇気づけられる本でした。
管理ゼロで成果はあがる?「見直す・なくす・やめる」で組織を変えよう
- 作者: 倉貫義人
- 出版社/メーカー: 技術評論社
- 発売日: 2019/01/10
- メディア: Kindle版
- この商品を含むブログを見る
RubyとRailsの学習ガイド2019は初学者のための世界地図だ
一緒に働いている 五十嵐 さんから頂いたので読んだ。
@igaiga555 さんに頂いてきましたー中身めっちゃ綺麗!! pic.twitter.com/r9dz9dqvFB
— Eiji Hachiya / はっちー (@hachi_eiji) April 15, 2019
初めてRuby,Railsを使う人向けの地図だった。1ツールだけであればGettingStartから読んでドキュメントを読むが、Ruby,Rails(というか昨今のWebアプリケーション)は本当にやることが多く、どこから手を付けていいか途方にくれることがよくある。その中で世界地図になる本だった。
各地方地図は各専門的な内容は既に著名な本が出ているのでそれらを紹介しつつ、Webアプリケーションを作るために抑える技術を網羅してあった。また、初学者は細かい字でズラズラと書いてあるとつかれるので比較的大きな行間で書かれていた。以前頂いた五十嵐さんの共著 ゼロからわかる Ruby 超入門 はじめてのIT技術講座 も本当に初学者が疲れないように書いてあったので、本当に気にしているのがよく分かる本だった。
なので、これからRailsを初めようという学生さんや、ちょうど4月なので新人研修をする人が、まず自分たちが踏み込んだ世界の一部を見るためには本当に良い本だった。まぁ、本書に書いてある内容地図はワンピースでいう「東の海」であり「偉大なる航路」ではないので、ラフテルへの到達方法は各自で探せる楽しみは残っている
10年ぶりぐらいに洗濯機を買うときに便利だったもの
ついにドラム式選択乾燥機を買ったがそのときに便利なものがあったので残しておく。 お店でゲットできるこの設置スペース確認シートだ。電気屋にあって、パナソニック、日立は出していた。シャープは見つけきれなかった
ちょっと画像汚いが、シートの中身はこの様になっていて各型番ごとに必要な長さが メジャー付きで 書いてある。
何が便利かというと
- 当然、購入前の下調べに必要なサイズを測る必要があるのではいる・はいらないの確認ができる
- 実際に業者さんが取付時に取付可能か確認するときに実際の製品スペックと取り付け場所を比べるときに便利
- これはまだ確認してないが、おそらく引っ越時にも使えるだろう
ということで、カタログだけではなくむしろこっちの紙をもらって保証書と一緒に保管しておくと良いと思う。
iPad mini 第5世代を買って読書が捗る
今まではiPad miniの第2世代を使っていてストレージサイズが足りなくなってきたり、動きがもっさりしてたので、先日発売された ApplePencil 対応の iPad miniを買った。
iPad Airを買おうか少し悩んだけど自分が持ってるボディバッグにもラクラク入るので結局miniにした。当初は動画を見るのを中心に考えていたが、(そのために画面に集中しやすいフレームが黒いスペースグレイを買った)、思ったよりも読書する時間が増えた。
今まで電子版の本を読んでもその辺のノートに書いたりDropbox Paperに書いたり色々していたが、ApplePencilを買ったことでデフォルトのメモアプリに統一した。(ちなみにGoodNoteも使ってみたが、MacとiPhoneとiPadで楽に同期を取ることを優先したので使ってない。)どうせ一度に読める量はたかが知れてるので、下のキャプチャのように半分は本、半分はメモにしてる。キーボードで打つよりも自分の手で書くほうが自分は記憶に残るので今の所このスタイルが合ってるぽい
Railsで検索条件を指定するときはプレースホルダーではなくHashにしたほうがいい
Ruby2.6 + Rails5.2の組み合わせでMySQLのdate型のデータに↓で実行したときにクエリが異なるのはなんでだろ?
— Eiji Hachiya (@hachi_eiji) February 12, 2019
d = DateTime.parse('2019-02-13')
<中略>.where("some_date=?",d).where(some_date: d)→<中略> WHERE (some_date = '2019-02-13 09:00:00') AND `some_dates`.`some_date` = '2019-02-13'
文字列の場合
下記の場所で タイムゾーン考慮処理と、 DateTime#to_s
を呼び出しているので時間まで残る
def quoted_date(value) if value.acts_like?(:time) zone_conversion_method = ActiveRecord::Base.default_timezone == :utc ? :getutc : :getlocal if value.respond_to?(zone_conversion_method) value = value.send(zone_conversion_method) end end result = value.to_s(:db) if value.respond_to?(:usec) && value.usec > 0 "#{result}.#{sprintf("%06d", value.usec)}" else result end end
rails/quoting.rb at e53430fa9af239e21e11548499d814f540d421e5 · rails/rails · GitHub で呼ばれているメソッドより抜粋
Hashの場合
こちらは DateTime#to_date
を呼び出しているので、時間は切り落とされて日付だけが返却される
def cast_value(value) if value.is_a?(::String) return if value.empty? fast_string_to_date(value) || fallback_string_to_date(value) elsif value.respond_to?(:to_date) value.to_date else value end end
rails/date.rb at e53430fa9af239e21e11548499d814f540d421e5 · rails/rails · GitHubより抜粋
いつから入ったのか?
どうもこれっぽい。
本来はどうあるべきなのだろうか
MySQL5.7で検証しているが 2019-02-13
を 2019-02-13 00:00:00
にしても検索結果はヒットする。しかし、しかし、MySQL5.6時点の
MySQL :: MySQL 5.6 リファレンスマニュアル :: 9.1.3 日付リテラルと時間リテラル を見ると 2019-02-13
== 2019-02-13 00:00:00
とはどこにも書いてない。Date型は日付だけを持っており時間を持っていないので当たり前だが。
DBという固く設計・実装すべき方に合わせるほうが良いので、プレースホルダーの方を日付型にすれば良いと思ったが、下記で話をされている通り、そちらはカラムの型を持っていないのでDatetimeなのかDateなのかわからないため変換ができない。
アプリケーションエンジニアができることはなんだろうか?
テストかけ
Classi Angular Night #1 を開催しての感想
Angular日本ユーザー会との共催で開催しました。関係者の皆様改めてお礼申し上げます。
身内だからというのも若干あるんですが わたる (@kasaharu) | Twitter が事例を話してくれて、派手さはないけど、正しく、奇をてらわずに作ってくれていることへ対してみんなが反応してくれていたのが一番印象に残りました。
難しいのはわかるけどそれをやらないと何年後かの自分たちが絶対に苦労するのは目に見えている(実際現在進行系で苦労してるし...)ので、自分たちがやっていることが決して間違っていないということを再認識しました。そういうのがきちんと評価したいし評価されたいですね。
帰り道にlacoさんとお話していて(酔っていたので若干異なってるかもしれないですが...) 仕事でAngularがこれだけ使われていて安心して使える。そしてどういうケースはAngularが適しているのかという事例を出していきたいですねーという話をしてくださいました。
仕事という実戦の中でエンジニアの技術力は磨かれていくと思っているので(もちろんそれだけではないけど)、仕事で個人の技術力上げる→ よいプロダクトを提供する→その知見をコミュニティに還元する みたいな循環ができれば、個人、企業、コミュニティともにwin-win-winになると思っています。
一例だと今のリプレイスプロジェクトはmultiple projects を採用してるのですがこれはng-japan 2018(at Google)で知ったものです。今はmonorepoで作るというのと将来的にはマイクロサービスとして分割していく可能性は非常に高いのでそこを意識して機能ごとにパッケージは別けたいというのはシステム作成時の制約として決めていました。
しかし、当時は最良の解決策を持っていませんでした。発表を聞いた直後にGoogleの食堂で二人で「いける?」「いけそう」というのを試してたのは今でも覚えています。
また、そのときに初めてAngular日本ユーザー会へ会社がスポンサーをしてくれたのですが、そこでうちに興味を持ってくれた学生が4月から社員として入ってくれる事になりました。もちろんAngular以外で作っているシステムもあるのでそういうのも知った上で入ってくれますし、大変なところも承知した上で入ってくれます(多分)。
そういう事例を作って循環の輪を作っていければいいなぁとは思います。
Angularでのローカル開発時に便利なProxyConfig
前提条件
ローカル環境での開発時にはMockAPIを返すサーバと実際のAPIサーバの2つを作ることが多い。そして小規模〜中規模のモノリシックなアプリの場合はユーザがアクセスするFQDNとAPIのFQDNが同じであることも多い。
課題
ただ、実際に開発するときにはAngularはWebpackのDevServerが4200ポートを使っていて、Rails,NodeなどのAPIサーバは他のポートを使わざるを得ない。これまで自分が作ったWebサービスではMockAPIと実際のAPIサーバのアクセスをどう切り替えていたかというと、environment.mock.ts とかのファイルにURLのフルパスを書いていた。npmから起動するときに ng serve -c=mock
とかでmockのconfigurationを読むようにしていた。
export const environment = { production: false, // api server api: { url: 'http://127.0.0.1:3000/api' } };
最大の問題はブラウザ上に表示されているFQDNとAPIサーバのFQDNが異なっていた。可能な限り実際のサーバ構成とローカル開発の環境は同じであるほうがいらないトラブルを減らせる。あとはMock用の設定とローカル開発用のAPIサーバの設定とかで個別でファイルを作っていた。
解決策
https://angular.io/guide/build#proxying-to-a-backend-server に書いてあることがすべて。 proxy.conf.jsonを作ってからangular.jsonに読み込ませることで設定終了という非常にお手軽。
{ "/api": { "target": "http://127.0.0.1:3000", "secure": false } }
in-memory-web-apiをつかわないのか?
自分はあまりAngularのチュートリアルでも出てくる GitHub - angular/in-memory-web-api を積極的に導入していない。(社内でやっているところはある) 理由はいくつかあって、