今年買ってよかったもの 2022 - Diary
今年買ってよかったもの 2022 こんばんわ。今年もいろいろ買っているので買ってよかったものをまとめていきます。 iPhone 13 mini 128GB docomo 版です。正月に東京中を徘徊して吉祥寺のヨドバシでようやく在庫確保して買いました。 MNP の弾はなかったので 2 年使って 2 万円です。 XR から買い替えました。 2 万円で買える携帯電話としては本当によいものだと思います。僕の手は面積としては手が小さい女性と比較してもかなり小さい、という感じなのでこのサイズは非常によいです。ただこうやって投げ売りされていることからあきらかな通り全然売れてないし今年からこのサイズなくなるらしいし悲しいことですね。 詳細は調べてほしいんですが 2 年後に没収されるかわりに 2 万で買える、という買い方をしていて実質的にはリースみたいなもんなので 2 年後に安い電話がないと結構面倒なことに
認証自作、 Rails 、 Devise - Diary
認証自作、 Rails 、 Devise https://ockeghem.pageful.app/post/item/uQFX4oRNbnax82V これを読んで思ったことなんですけど、 Ruby On Rails 界隈では「認証は自作すべきではない、デファクトスタンダードの Devise を使うべき」という考え方が一般にあるように思います。 ではその Devise なんですけど、ドキュメントに以下のようにあります。 Starting with Rails? If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we ad
仕事と給与と評価の関係 - Diary
仕事と給与と評価の関係 (1) 仕事の成果を適切に評価することは困難です 営業なら売り上げだろ?違います。売り上げまくってるけど CS 部門に迷惑かける客ばかりつれてくる人とかいますよね。 CRM 使えばそういう人を適切に評価することができるかもしれませんが、大抵おとぎ話でしょう。 (2) 給与ははっきりいって適当に決まります、運です 評価制度やグレード制度が決まってる場合でも結局その運用は最終的には人手なので、、、 (3) 「会社の利益を意識せよ」と言ってくる経営者を信用してはいけない そういうことはスタッフグレードの人が考えるのであって、現場はそんなことを考えないといけないのであれば組織が成り立ってない。「会社の利益を意識する」というのは「情報の収集と評価」とより抽象化できるが、それは非常に高度で専門的なミッションであって、そんなことを片手間にやると業務執行の質がガタ落ちします。下級管
最近ユビレジではじめた Slack チャンネルの新しい運用 - Diary
最近ユビレジではじめた Slack チャンネルの新しい運用 なんですが、ユーザーサポートから開発者への問い合わせが作成されると自動でそれに対応する Slack のチャンネルが作成される。それは開発者全体チャットみたいなチャンネルに通知される。ユーザーサポートから開発者に問い合わせがくる場合というのは、大抵なんらかのソフトウェアの不具合である。 するとその問い合わせにある問題について知識のある開発者がそのチャンネルに入ってあーでもないこーでもないみたいに議論しながら対応してサポート担当者やら関連する案件の提携先企業やらとやりとりする。また障害であればそこで対応作業の内容を逐次事前に通告して他のメンバーのレビューを仰いでから行う。結果についても遅滞なく報告する。 このようにしているといずれ障害や問題は解決するので、その時点でそのチャンネルはアーカイブして社内 Wiki に簡単な概要を作成する。
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる - Diary
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。 Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。 本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだい
Firebase でバックエンドエンジニアがいらなくなるは正しくない - Diary
Firebase でバックエンドエンジニアがいらなくなるは正しくない と思っている。 用語定義が曖昧だが、「バックエンドエンジニア」という言葉でなんとなく想像されるものとしては、 Rails とか Laravel とかでデータベースに CRUD する Web アプリケーションを書ける人を指すと思う。違いますかね。そんなに違ってないと思うが。 Firebase でこれらの知識をもつ人が不要か?というとある程度の規模、機能を持つアプリを作ろうと思うとこれは必須になる。 Firebase のデータベースは機能が少なく(とはいえ Firestore はわりと「これで十分じゃん」ではあるが)、なにか複雑なことをしようとすると、すぐに Cloud Functions という機能に頼ることになる。 Cloud Functions はようするに Firebase の Lambda + API Gatewa
日報の再発見 - Diary
ぼくはこんな資料を持っています。おそらく、公安警察の警察官が私的にファイリングしてきたものだと思います。そこに、以下のようなものがあります。 これをファイルした警察官の素性について、ぼくは全く知りません。ですが、彼は「捨てろ」という指示を守らなかったわけです。ここに載っている門脇なる人物は白鳥事件の関係者なので、これはおそらく 1950 年代に作成されたファイルでしょう。 「旧軍の戦闘詳報ですらちゃんと残ってるんだから自衛隊の日報がちゃんと管理されてないわけない」みたいな意見ありますが、少なくとも警察においては 1950 年代の時点で「資料を焼け」と上層部が指示し、そう言われた警察官はその命令を無視して勝手に資料を保管する、そんなふうになっていたわけです。 結局のところその旧軍の文書管理にしたところで上っ面だけをまねた猿真似にすぎず、情報を大量に蓄積して活用するなんて考え方は日本に定着した
日報 2005 年分はとりあえず全部読んだ - Diary
日報 2005 年分はとりあえず全部読んだ その結果の感想としては、やはり https://diary.app.ssig33.com/349 で書いたような事態である可能性は高いと思う。 不審なバナナ売り pic.twitter.com/iI0UZ8aGE2 — 小池 陸 "病気のエビ" (@ssig33) April 16, 2018 やっぱこれ公式に残してたものじゃないんだろうなあ、、、こういう書き込みからするに pic.twitter.com/A4BD1aHtUU — 小池 陸 "病気のエビ" (@ssig33) April 16, 2018 のように受け取った人がメモを書き込んだ形跡が多々あるので。 あと思うのが、この日報はいったいどのように活用することを前提に作っていたのか？これを毎日読んだところでイラクの政治情勢にかんする現地の軍人のいまいち信用できない情勢判断ぐらいしか結局頭
見てるページを全部保存するという行ない - Diary
見てるページを全部保存するという行ない をもうずっとしていて、以下のような user.js でページを全部保存してます。 // ==UserScript== // @name 見たサイト全部保存 // @namespace http://tampermonkey.net/ // @version 0.1 // @author You // @match http://*/* // @match https://*/* // @grant GM_xmlhttpRequest // @noframes // ==/UserScript== if(!!document.querySelector('title')){ const title = document.querySelector("title").textContent; const url = location.href; GM_x
Heroku でのスケジュールタスクの実行(Rails の場合) - Diary
Heroku でのスケジュールタスクの実行(Rails の場合) Heroku ではいわゆる cron 的なことをしたい人のために Heroku Schedulerというものが用意されています。 ですがこれはかなり問題の多いプロダクトで、シリアスな業務で用いるにはいろいろと厳しいです。まず設定 UI が非常に貧弱で、設定ミスをしても気付きづらいです。またセッション管理の点にも問題があり、自分がいじってるつもりと別アプリの設定をいじってしまうという事故はわりとよく起きます。 そして最大の問題ですが、公式のドキュメント Scheduler job execution is expected but not guaranteed. Scheduler is known to occasionally (but rarely) miss the execution of scheduled job
優秀なプレイヤーを管理職にするなとかよく言うけど - Diary
優秀なプレイヤーを管理職にするなとかよく言うけど すくなくとも俺はプレイヤーとして自分よりダメな奴に管理されたくないんだよな。いいコーチはかならずしもいいプレイヤー出身じゃないとかよく言うけど、それは横綱クラスじゃないという話であって幕下の奴がいい親方になるのか？優秀なプレイヤーを十分集めてそのなかから管理職をやりたがっててかつその能力のありそうな奴を管理職にするべきなんじゃないのか。
OSS 版 Fastladder で LDR と全く同じインターフェイスでフィード読む - Diary
OSS 版 Fastladder で LDR と全く同じインターフェイスでフィード読む というようなことをやっていきたい人がいると思います。 1. さくら VPS 契約する 1,706円/月 のメモリ 2GB プランがいいと思います。ストレージは SSD じゃなくて HDD にしときましょう。 2. 環境のセットアップ 面倒がすくないと思うので、標準 OS の CentOS 7 でサーバーを起動してください。このへんよくわからん人はさくらのマニュアルみて。 3. Docker のインストール root ユーザーか sudo 実行できるユーザーで以下を実行してください。 SSH とか分かんない人はあきらめるか調べろ！！！ # curl -fsSL get.docker.com -o get-docker.sh # sh get-docker.sh # service docker start
Web アプリケーションのインフラ等の即応対応要員の問題だが - Diary
Web アプリケーションのインフラ等の即応対応要員の問題だが 、単純にいって 1 年間は 9000 時間弱ある。一方人間の稼働時間はというと、土日祝日盆正月で 120 日、これに年次有給休暇が 10-20 日はある。 Web 業界では平均勤続年数がさほど長くないからここでは有給 15 日で計算するとして 230日 * 8時間 で 1840 時間ある。 面倒なので 1800 時間としよう。 単位時間あたり二人の要員をアサインする場合 8 時間交代でぎちぎちに監視スケジュールを組んだとして単純にいって 10 人いれば事は足りるということになる。突発的な事態については他の開発者にも応援を要請するとしても、とにかく 10 人は必要である。 実際のところ、昼間の業務から完全に外してとかじゃなくて、昼間のインフラ開発の業務も行いつつ定期的に深夜番や早朝番などを続ける形で入れていくことになるだろうが、総
IT 技術者に必要なコミュニケーションスキルとは何か - Diary
IT 技術者に必要なコミュニケーションスキルとは何か というと、それはもう以下の二つに集約されます。 出来なさそうな時は出来ないと言う 作業単位は小さくして早めに報告する 1 に関してですが、出来ると言っておきながら出来なければそれは作業者の責任ですが、出来ないと言ってそのままチームとして改善がされずに出来なければそれはもう管理者の責任です。管理者としても早めに言ってもらえれば対処できるんだけど、、、みたいなふうに思ってることが殆どだと思うので、仕事がダルかったら早めに言うべきです。「えっお前さっきは出来るって言ってたじゃん」みたいなことを言ってくるタイプのリーダーがあなたの上司なら今すぐ転職先を探しましょう、まともなリーダーはどこにでもいます。 2 ですが、これは Pull Request は小さくしてくれという話 Refactor hogehoge impl. hugahuga of
インフラエンジニアのいない会社で働いて 1 年半 - Diary
インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。 本当に自分達でなにもサーバーを管理してい
みなし残業の件 - Diary
みなし残業の件 みなし残業は n 時間までは残業していることにみなす、という制度なので当然それ未満の残業時間でもその額を貰えるので定時で力強く帰っていけば丸儲けということになる。 じゃあだからといって帰れるかというのは 本人の性格 会社の雰囲気 というのが関わってくる。このとき、どんなタイプの雰囲気の場所でも平然と帰れるトレバー・フィリップスみたいなタイプの人間が帰ればいいじゃんみたいなこと言いがちなんだけど、帰れる人間の方が少ないんだよ。それが分からんからお前らはトレバー・フィリップスみたいなタイプの人間しかまわりにいないんだよ。 というのがある。大抵の IT エンジニアは世間知らずで気弱なので帰れないし、さらには残業代不払いのような明確な犯罪行為にもまともに対抗できない。 実際問題いざとなったら帰れる奴のほうが基本給とかも高い地位にいることが多いし、自分の意思を貫き通す訓練みたいなこと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
