組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」

最近何をやっていたかというと、タイトルの通り、Pathtraqというサービス、iPhoneアプリを作っていた。どんなサービスかと聞かれるとLifeLogというのが一番適切だと思うけど、LifeLogにも種類があって、これは位置情報を記録して検索するサービスになる。 https://pathtraq.tagomor.is/ PathtraqApp Satoshi TagomoriProductivityFreeapps.apple.com どういうためのものかというと、普段生活したりどこかに行ったりして、以下のようなことが気になる方向けです。 この場所/店/街、最後に来たのいつだっけ? 前に飲みにいってふらっと入ったあの店、どこにあった何ていう店だっけ? 前にあそこからあっちに移動したとき、どのくらい時間かかったっけ? なんかさあ、この程度のこと、全部記録とってあれば簡単にわかるはずなんだけ

動機これまで40インチ湾曲ウルトラワイドモニターを利用してきました。 1人の作業はやりやすいのですが、web会議での画面共有がつらみでした。 アスペクト比が一般的ではないので、モニター全体を画面共有すると、他の人には、横長で小さな表示になってしまいます。個別のアプリだけを共有すると、アプリの切り替えで時間がかかってしまいます。 普段はクラムシェル運用ですが、ミーティング時だけノートPCを置くスペースを作ったりもしました。が、準備を忘れると時間を取られてしまいます。 現状、仕事には3台のPCが必要です。切り替えたり、同時に並べたりして作業を進める必要があります。 40インチのウルトラワイドモニターでは、画面を分割して、PC2台を同時に表示できるのは良かったのですが、ミーティング開始後に気づくと、画面分割の切り替え時に接続が切れてしまいます。 ミーティング時だけ準備が必要な運用はつらいことがわ

先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの

「次の職場が Ruby なんだけど」と読み書きそろばんを聞かれたのと、大阪Ruby会議03、大江戸Ruby会議10、Kaigi on Rails 2023 と Ruby/Rails 関係のイベントに続けて参加して、作者の皆さまと会ったので。 「読める」になるために 言語仕様は何らかの本 1 冊の冒頭の方を読めば雰囲気は掴めるだろう。 Ginza Rails27 igaiga - Speaker Deck 著書や技術顧問、健康診断レポート でお馴染みの @igaiga555 さんの作った表で、難易度別にまとまっている。 たのしいRuby か、プロを目指す人のためのRuby入門 が定番かなぁ。 できることを知る るりま (Ruby リファレンスマニュアル) の Enumerable、String Rails Guides の Active Support Core Extensions 日本語

ついに HHKB Studio が発表・発売されました。 ※発売直後に売り切れてしまっていましたが、今日 10/31 に再入荷されるようです。 ※10/31 の販売も即完売になってしまったようです… 次回入荷は 11 月中頃とのこと。 HHKB Studio ポインティングスティックとジェスチャーパッドの追加と、なんと言っても HHKB の名を冠しながらメカニカルキースイッチを採用するなど、大きな変化に興奮と動揺があったことは発表後の各種 SNS の反応からも窺えます。 実は HHKB Studio にはキーボードニュース の ぺかそ @Pekaso とともに開発の後半 (最終製品に近い検証モデルはすでに作られているぐらい) の段階からおよそ 1.5 年に渡って「後期アセスメント」に関わってきた経緯があります。また、HHKB エヴァンジェリストとしてここ 2 週間ほど最終製品を先行して使っ

軽くリファインメントをする時間 いまのチームでは、デイリースクラムのあとに毎日15分だけ、軽くリファインメントをする時間をとっている。目の前のスプリントのタスクのことをいったん忘れて、次のスプリントやもう少し先のことについてチームで相談する時間。 そこでは、PdM（プロダクトマネージャ）が「こういうこと考えてるんだけどどう思う？」って話をしてくれたり、エンジニアが「このあたり早めに改善しておきたいんだよねぇ」って話をしたりしている。 こういう軽い相談の場とは別に、もっと深く議論したいと思ったり、要件がかっちりと決まってきたりしたら、別途時間をとって、軽くないリファインメントでしっかりと相談している。 軽いリファインメントが結構好き 僕はこの日次の軽いリファインメントが好き。自分の「技術的な部分の改善をしたい」という考えをふわっとしてる段階で聞いてもらえるし、PdMがプロダクトの機能追加や改

私のためにおっパブ行ってください 起田ねぐせ となりのヤングジャンプにて読切『そして、化けの皮は剥がされた』が掲載中。

2023/10/25発売のHHKB Studioを購入し、構成・構造を細部まで検証したのでレビューします。 注意: 詳細レビューは執筆中で、随時追記しています。ひとまず総評まで読んでいってください。 レビューする私の立場 私はHHKB Studioの購入者です。 特にどこからか提供や依頼を受けてのレビューではありません。 またHHKBの従来品の愛用者でした。 初期のHHKB Professionalから始まり、 Pro 2、Type-S、HYBRID Type-Sまで色違いや予備品も含めて 合計7台を所有しています。 加えて2020年末より自作キーボードに傾倒しました。 短期間で大量のキットを組み立てたり、 自ら回路を設計したり、 ファームウェアを書き起こしたり、 あのKeyballシリーズのファームウェアを担当したり と 自作キーボードとポインティングデバイスに関する一定以上の知見を持っ

水着の女です。 にことがめ 日々の仕事に忙殺される独身男性の自宅に、 ある日突然水着姿の女の子が現れる。 彼女は何者？そして、その目的は…！？

ポインティングスティック、ジェスチャーパッドを搭載した「HHKB Studio」新登場 HHKB配列の継承とカスタマイズ性を合わせ持つAll-in-Oneモデル 株式会社PFU（代表取締役社長：村上 清治、以下 PFU）が開発・販売する高性能コンパクトキーボードHappy Hacking Keyboard（以下HHKB）シリーズは、新たにAll-in-Oneのコンセプトを加えた「HHKB Studio」をPFUダイレクト（注1）にて本日2023年10月25日より販売開始します。 「HHKB Studio」はPFU の米国拠点であるPFU America, Inc.にて企画し、Huge Design LLC.（米国カリフォルニア州）にデザイン協力を得て開発した新しいラインナップのHHKBです。 「HHKB Studio」は、HHKBの合理的なキー配列を継承し、ポインティングスティックとジェス

16bitセンセーションAL。第3話でした。 みなさん、お祭りを楽しんでいますか？ どんどんつぶやいてくださいね。 今回はコノハは1996年にやってきました。 郄橋さんが、こないだおっしゃってたんです。「なんだかんだ言ってみんなアニメ16bit観るでしょ！って若木さんが仰ってたの聞いてボクは本当に？ って思ってたんですけど、その通りでしたね」と。そりゃ見ますでしょ…。世の中には想像以上にエロゲを通っている人が多いんですよ。想像の16倍多い。なのになぜ今まで同じものがなかったのか。 ゼロ年代エロゲで同じことやったらもっとバズるかも知れないな…。まあ、そんな近い時代(ボク基準)やってもあんまり面白くないけどね！！ボクは、「痕」と「Piaキャロ」が同じ日に出てたよ。ということを今改めて知ってもらいたかった。在りし日のメッセサンオーを画面に映したかったん。これでこのアニメはもう役割を果たしましたよ

2023年10月 LayerX全社朝会資料より

私が様々なビジネススキルの中で最も重要と考えているのが「質問力」です。 これをなんとかお伝えできないか、と考えたのが、雑多な本から質問に関する記載部分を抜き出してみること。お役に立つか分かりませんが、個人的には改めてその重要性を認識する結果になりました。こんな読み方も面白いですね。 （なお、対象としたのは、手の届くところにあった「質問」をテーマとしていない本、となります。若干古めなのはご容赦ください。） ご注意）気がついたら4千字を大きく超える分量になりました。ほとんど引用ですがあらかじめお断りさせていただきます。申し訳ありません。 1、まずは「質問」の重要性をズバッと指摘するこの2冊から 「もし自分が死にそうになって、助かる方法を考えるのに1時間あるとしたら、最初の55分は適切な質問を探すのに費やすだろう」と言ったのはアインシュタインです。 （『「すぐやる人」と「やれない人」の習慣』94

はじめに しまねソフト研究開発センター（略称 ITOC）にいます、東です。 教育用ワンボードマイコンとして販売されている Raspberry Pi （以下ラズパイ）は、教育用のみならず実験用、産業用とさまざまな分野で使われつつあります。一方、マイクロSDカードをメインストレージに使用している事や、OSがクライアントPCよりの設定にしてある事などから、長期安定運用には向かない面も存在します。 このレポートでは、OSや稼働させるソフトウェアの設定など、できるだけ簡易に再現可能な方法により、可能な限りラズパイを安定して長期運用させることを狙います。また、その題材として、デジタルサイネージ(*)を作ってみます。 私は、2000年ごろからフラッシュメモリを使ったFA機器の開発を皮切りに、10年ほど前からは民生用フラッシュメモリ（CF,SD,USBメモリ）を起動デバイスとした機器を開発・運用していまし

scala-tokyo.connpass.com 株式会社はてな 東京オフィスで開催されたScalaわいわい勉強会に参加した。 発表内容の感想ではなく、参加して漠然と思ったことについて書く。個人の日記です。 Scala、10年前に本当に少しだけ触った程度で何も覚えていない（github.comに辛うじてコードが残っている）のだけれど、 この1年はJVM言語で仕事をしているのもあり、勉強会の運営をしている id:Windymelt にも紹介いただいたのもあって、ふらっと参加してきた。 Scalaのコミュニティというか関数型プログラミング言語のコミュニティ、ふらっと参加するには恐れ多い印象があったのだけれども*1、 これくらいのノリであれば全然次回も参加したいな〜となるくらいの感じであったな。 参加前に これだけ読めばOK！Scalaの環境構築2023 - Lambdaカクテル を読んでて、手

最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作

昨日、ゆのんさん（ https://twitter.com/yunon_phys ）が社内の勉強会で「エンジニアリングマネージャとは？」って話をしてくれて、面白いなぁって思いながら聞いてた。 今日は @yunon_phys が社内勉強会で、エンジニアリングマネージャについてお話をしてくれてとてもよかった。こんな話が社内で聞けるのって福利厚生だなぁと思いながら聞いてた。— SHIIBA Mitsuyuki (@bufferings) October 13, 2023 その中で「エンジニアリングマネージャが見ることのできる範囲はめちゃ広いから、すべてを完璧にしようとするんじゃなくて、その場に応じてスキマを埋めるような動きができるといい。組織の成長とともにその動きも変わっていく」ってことを言っていて、これって自分のソフトウェアエンジニアとしての動きにも似たところがあるなぁと思ったので雑にメモ。

mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死

こんにちは。CTOのid:motemenです。みなさん趣味プログラム書いてますか？ このエントリは Backyard Hatena #4 のフォローアップ記事です。エピソードの最後のほうで、「motemenが作って公開しているツール、どんなことを考えて作ってる？」という話になりました。そのときは時間の関係もあってあまりちゃんと話せなかったな、という感覚があったので、ここであらためて考えてみようと思います。 治具のようにつくる ウェブ上で読める自分が好きな記事のひとつに、Go Is a Shop-built Jig（抄訳）というものがあります。一言でいうと、「Goは現実的な問題を解くための治具である」ということをいっています。治具とは何かを達成することを補助する小さな目的のために作られた道具、という感じかな。fujiwaraさんの隙間家具のたとえからも近いニュアンスを感じます。 自分がツール