ナレッジワーカーの集団にとってのアクセルは文化、ブレーキはルール。文化は行動が作る - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
よく、「仕事の属人性を排除して、仕組みやルールで標準化すべき」ということが言われる。これは決して間違えていないと思うけど、一方で片手落ちだと思う。たしかに、労働集約型の事業においては、「人数を増やせば増やすほど利益につながる仕組みやルール」を作ることが大事になるだろう。一方、知識集約型の事業においては、これは必ずしも真ではないと思う。 言ってみればあたりまえのことだけれど、ルールや仕組みは、増えれば増えるほど労働は平準化されていく。労働集約型の事業においては、「ローパフォーマーを減らすこと」のほうが、「ハイパフォーマーにさらに高いパフォーマンスを発揮してもらうこと」よりも重要だ。だって数がたくさん必要なんだもん。そのため、ハイパフォーマーにとっては「枷」になってしまうようなルールや仕組みであっても、その仕組みを課すことでローパフォーマーでも一定のアウトプットが出ることが重要となる。つまり、
RailsのControllerにApplicationService相当のロジックを書くのはありなしや？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。 Railsにおいては、ApplicationService相当のロジックをコントローラーに書いても良いものとする— 猫でもわかるしんぺい入門 (@shinpei0213) June 4, 2019 これについてです。 結論から先にいうと、ぼくは「正しい」と思っています（ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています）。 なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplication
心理的安全性を獲得しにくい個人(は|を)どうすればいいんだろう - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
心理的安全性ということばはだいぶ浸透してきて、とくに説明なくみんなに通じるような感じになってきているけれど、まあなかなかに難しいものだなあと思う。 組織やチームのまとめ役となる側からすると、心理的安全性が確保できるチームをどのように作っていくか、という点に注目があつまりがちなんだけど、個々人が心理的安全性を獲得するときにも、それぞれの性格によって難易度に差があるよね、ということについて書きたい。言葉を変えると、多くのひとが問題なく心理的安全性を獲得できるような状況やチームであっても、自己肯定感を適切に持つことが難しいようなタイプのひとは、なかなか心理的安全性を獲得できないという問題（問題、というと語弊があるかもしれないけど、problemというよりもissueという意味での問題）があるんじゃないか、というような話だ。 自分にそういうところがあるからこの話をするのだけれど、わたしは「他人が自
ReactNative + Scala.jsファーストインプレッション - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ちょっと訳あって仕事の一貫としてReactNative + Scala.js の技術検証している。あたまには「全部C#」のライフベアさんの事例がある。弊社、最近メンバー増えてきたけどまだこの規模だと「あのひとはあれができるけどあのひとはこれができなくて」がボトルネックになりうるので、 筋の良い 共通の基盤技術を持つという選択肢のひとつとして検証したいというのがモチベーションとしてある。というわけで、 Reduxは使ってない。「Scalaを基盤技術にしてどこまでできるのか」が検証の目的だから。 Vue.js + Scala.jsでElectronアプリ作ったときと同じ感じで、MVWhateverのVとWhateverの部分は素直にJSで書いている。分厚いMをScalaで書き、UIだけReactNativeで記述する。 以下ファーストインプレッション pros Vue.js + Scala.j
ブラウザアプリケーション以外のプラットフォームでのReduxはtoo muchか？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
@Nkznとかが最近よく言ってるReactNativeではReduxじゃなくていいんじゃない？って話。Electronでも同じような議論が可能だと思うので、さらに一般化して「ブラウザアプリケーション以外のプラットフォームでJSで動くGUIアプリケーションでReduxは必要なのか？」という話をします。 結論から先に言うと、わたしも「ブラウザで動くわけじゃないなら、Reduxである強みってそんなになくなるよね」という立場です。 まず、前提として、Fluxは「状態管理パターン」で、Reduxは数あるそのパターンの実装のひとつである。ということを確認しておきましょう。 その上でReduxの特殊性は Stateがピュアなオブジェクトで表されている Stateの更新はイベントを契機に常に同期的に行われる 以上2点により いつでも状態のスナップショットをシリアライズ/デシリアライズ可能な形で取得できる
わたしがあまりHMR（Hot Module Replacement）を好まない理由 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
JavaScriptニュービーです。ニュービーなので界隈のHMRに対する評価がどんな感じなのかよくわかっていないのですが、個人的には採用しない理由のほうが多いと感じています。 というのも、「開発効率がちょっとよくなる」というメリットに対して、 HMRに対応するために、ユーザーが触るプロダクション環境には関係ないコードを書かなければいけない プロダクション環境で起こり得ないことが起こる仕組みが開発時にのみ入ってくる というコストを支払う価値が高すぎると思っているからです（あと、リロードで壊れないSPAを作るためには意外とHMR入れてても開発時にリロードする気がする）。 単純にわたしがHMRよく理解できてない or 知識が古い可能性もあるのでその場合は教えてください。
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / Scala.jsについて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに オフラインファーストへの要求 近年、オフラインファーストというか、「オフラインのときにも普通につかえて、オンラインになったら同期する」みたいなことに対する要求が高まっているように感じます。 その場合は、ローカルにもきちんと永続データを持っておき、オンラインのときにバックエンドと通信をしながらバックエンドのデータと同期していく、というスタイルを考えるのが自然だと思います。 また、普通のJSアプリケーションであっても、「サーバーに投げる際に失敗したデータはローカルでメモリ上にもっておいてリトライしたい」などの要求もあるでしょう。 さらに、ここでモバイルアプリも視野に入っているとなると、どうしても「オッRealm Mobile Platformか！？」という感じが出てきますが、Realm Mobile Platformにロックインされるのと引き換えに開発の速を選ぶのか、それとも、という
RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
Niigata.pm 決起集会をやってきました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
昨日の話になりますが、Niigata.pmの決起集会をやってきました。 長岡のよくわからないお店で、最初ちょっと「えっここ大丈夫なの…」と思ったんですけど、電源も貸してくれたし普通に良心的な感じでよかったです。 印象に残った話としては、長岡技術科学大学の知識システム研究室の学生さんが、結構以前からあるweb上の資料などを参照する形でPerlを学んでいるらしく、(ishiducaさんも言っていましたが)このあたりはNiigata.pmでPerlビギナー向けのハンズオンをやるみたいな形でなんかフォローできたらいいなぁと感じました。hayajoさんあたりが実現してくれるでしょう(無茶ぶり)。 発表に関してはhayajoさんのfluentdの発表が結構参考になったのと、今まで手動で毎日三回以上検索していたプリキュア情報を自動化してメール(etc)通知するようにした話(正しいエンジニアリングだ…)と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
