サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
blog.stenyan.jp
私はアメリカの大学で「インタラクティブメディアとゲーム開発」を専攻しましたが、その時受けたSoftware Engineeringという授業が色んな意味で素晴らしかったのでその授業がどう素晴らしかったのかを紹介していきます。 リアリティーがすごい まずこの授業、生徒数が80人ほどいます。ここから教授がみんなを約15人ずつの5つの会社に分けていきます。そうです、我々生徒は実は会社員なのです。 そして初日に出された課題は「自分たちの会社のミッションステートメントを考えてくること」です。 それだけでなく、プロジェクトマネージャー・プロセスエンジニア・リリースエンジニア・ドキュメンテーションマネージャー・クオリティーマネージャーの役割を会社のどの社員が取るのかを決めてこないといけないというのです。私たちは言われるがままにミッションステートメントを用意し、次の授業に備えました。 プロセスがすごい S
前提 僕は新卒からいまの会社に入って以来ずっとWeb系アプリケーションエンジニアとして仕事してきました 自分がWeb系のエンジニアとして成長するにあたって必要なスキルについて考えたときに、ただコードが書けるだけでは評価されないだろうなということだけ何となくわかっているつもりだけど、言語化しないとどういうスキルがあるのか何が自分に足りないのかがわからない気がするので一旦ブレストしてみる 出来上がったリストを元に次にどこを集中的に伸ばすべきかというのがわかるのではないか ここでいう暗黙的とは、僕が学生の頃「Web系のアプリケーションエンジニアに必要なスキルはこれだろうな」と考えたときにきっと思い浮かばなかったもののことですが、人によってはこんなこと当たり前だろうと思うかもしれません ブレスト結果 いくつかブレストした結果をグループごとにわけてみた。(ブレストといってもただパソコンに向かって箇条
この記事ははてなエンジニア Advent Calendar 2020の6日目の記事です。 qiita.com 5日目は id:mizdra さんによるpolyfill を深堀りするでした。フロントエンド周りは弱い自分としてもこの記事を読むだけでpolyfillの概要から今後どうすると良いかなど知れてとてもありがたい記事でした。 www.mizdra.net さて今日は視点変えてツールの話を書きます。毎日使っているツールこそ、提供されている便利な機能を把握しておきたい。Macで使ってるターミナルアプリ「iTerm2」について書きます。 iterm2.com まずはみんながひょっとしたら知らない基本操作についていくつか紹介し、後半はTriggersという機能の使い方をいくつか紹介します。 (記事執筆時点ではver.3.4を使っています) tl;dr 公式ドキュメントにいろいろ書いてあるので読み
つみたてNISAといえば年40万円までの非課税枠があるが、12ヶ月では割り切れないので設定するときに工夫が必要ということが知られている。自分はSBI証券を利用しているがこの設定をミスって4円余らせたことがあるので一応ブログに書いておきます。 ボーナス月を指定しているのに4円余らせる設定 (うまくいかない) 毎月33333円積み立てて、ボーナス月に100円、NISA枠ぎりぎり注文を有効にする。(ボーナス月は最低100円からとなってるのでこうしている)。 うまくいかない設定ボーナス月とNISA枠ぎりぎり注文を使うのはFAQにも書いてあるし、上記の設定では12月のみ33337円積み立てられてほしい。が、実際には失敗します。 faq.sbisec.co.jp おそらく原因としては、12月時点でのNISA投資可能枠が残り4円になっているともう発注ができないということになるため。これはさらに別のFAQ
Webアプリケーションエンジニアをやっていると時たま障害が発生し復旧作業にあたるのだが、人によって「障害対応が得意」だったり「苦手」だったりする。ただ、障害対応時の「良い動き」というのが実際どういうものなのかというのが自分の中でふんわりしていたので、ざっくりはてブで「障害対応」で検索していくつかのエントリーを読んでみたり、自分の仕事での経験を振り返ってみたりして考えたことをまとめてみた。 障害にはフェーズがある 障害対応には複数の役割がある 障害対応をスムーズに進めるための目的は複数ある スキルも必要なので練習していけると良い 初心者でもやれることはある 実際やってみると良さそうなこと 障害対応時にやることをテンプレート化する スムーズに対応に入れる仕組みを整える 障害対応避難訓練 おわり 障害にはフェーズがある 障害対応したことないと、障害には「障害中」「障害中でない」の二つの状態しかな
English translation of this post: Read the book "The UNIX Philosophy" | stefafafan's tech blog あけましておめでとうございます。『UNIXという考え方―その設計思想と哲学』という本を読んでいたら年越していました。 この記事は はてなエンジニア Advent Calendar 2022 の 1月1日の記事です。*1 昨日は id:tkzwtks による コーポレートサイトドメイン引越しの裏側 - Hatena Developer Blog でした。 今回は表題の本を今更ながら読みましたので、感想を軽く書きます。 この本で紹介されている9つの定理 設計思想に関する定理 開発プロセスの話 細かい手法の話 全体的な感想 この本で紹介されている9つの定理 この本では以下の9つの定理が紹介されていました。 ス
私はいま会社でテックリードをしていますが、いちエンジニアとして技術的改善をチームに提案するスキルに関してまだ課題感を持っています。その際同じくチームに所属しているエンジニアリングマネージャー(EM)の方にヘルプしていただき、実際に提案資料をペアライティングした中で湧いたイメージがあるのでブログとしてまとめて自分の考えを整理してみようと思います。 効果的なストーリーテリングのための既存のフレームワーク 技術的な提案をするには効果的なストーリーテリングをするスキルが必要だと考えています。私はストーリーテリングに関して詳しくありませんが、仕事を通じて以下の二つのフレームワークを知りましたので軽く紹介します。世の中には他にもいろいろあると思いますが、基本的な考え方は近いのかなと想像しています。 空・雨・傘 STARフレームワーク 空・雨・傘 EMの方と会話する中で「空・雨・傘」というフレーズを何度
同僚が1on1の際に他の人がどういう話をしているのか気にされていたので、便乗してブログに書きます。 ということで人が1on1の時間に何を考えてどう使っているのか気になっている1on1で何を話すか考えてる - tomato3713’s blog 前提 株式会社はてなは新卒から所属しており、今年で9年目 現在チームでテックリードをしている。Webアプリケーションエンジニアとしてコードも日々書いている とはいえ自分もメンティーは持っていなくて、1on1してもらう側の1人 最近1on1に向けて考えていること 前提に書いてある通り、自分はこの会社では古参で普段の仕事の仕方だったり同僚とのやりとりやカルチャーについての大きな悩みや不安はないです。その代わり、テックリードや30歳になったエンジニアとしての悩みや考えはあります。ということで以下のようなことを考えています。 テックリード どのような振る舞い
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
分報チャンネルとは そもそもなんだという人はこの辺みてください。 http://c16e.com/1511101558/ blog.animereview.jp 要するに日報よりも細かい粒度で好きなように自分専用のチャンネルで書いていくという感じですね。 やめるまでの経緯 最初は好き放題かけて気分が楽だし、困ってるときは自分の分報チャンネルに入ってくれてる優しいかたが助けてくれる・わいわいしてくれるみたいな感じで良さそうって感じでした。 気がついたら自分のチームのメンバーが増えていって、メンバー全員のチャンネルに入るとそこそこな量になるようになってきた。別に常に全員がその瞬間何してるのか追ってる必要もないし、そもそも私は若手エンジニアということでまずは自分の仕事をしていくことが大事では?ということで他人の分報チャンネルから次々と抜けていくことにしました。 こういう話も上がった @daiks
こちらははてなエンジニアアドベントカレンダー 2016の11日目の記事です。 developer.hatenastaff.com 前日は id:Windymelt さんの「趣味のプログラミングから職業としてのプログラミングへ」でした。 windymelt.hatenablog.com 今回はAWSサービスをいくつか触ってみた話について書きたいと思います。 やったこと EC2 インスタンスの作成 VPC VPCの作成 サブネット サブネットの作成 インターネットゲートウェイ インターネットゲートウェイの作成 ルートテーブル ルートテーブルの作成 IAMロール セキュリティグループ セキュリティグループの作成 RDS RDSの作成 ALB ALBの作成 ターゲットグループ ターゲットグループの作成 ヘルスチェック ALB vs. ELB, CLB NAT Gateway NAT Gateway
去年認定スクラムマスターになって、実際に自分の開発チームにScrumを導入したり、最近ではチーム内でテックリード交代して開発プロセスの高速化についてより考えるようになってきた。 Agile, Lean, XP, DevOps, Four Keys, Team Topologies など様々なフレーズを見かけたり本を読んだりしたところ大体皆同じ場所を目指していると感じるけど、イマイチ自分の脳内インデックスが貼れていない気がしたのでこのエントリで軽く考えを整理してみようと思う。 とにかく改善のサイクルが回っていない (ソフトウェア開発に限らない) 開発速度が上がらない (ソフトウェア開発者側) Extreme Programmingのプラクティス DevOpsのプラクティス チーム内での連携が上手くいっていない チームの構成がイマイチ・他チームとの連携が上手く取れていない まとめ とにかく改善
2024年1月31日を最終出社日として、新卒から8年半ほど勤めていた株式会社はてなを退職します。次の会社は決まっていますが、そちらについては入社エントリでお話しします。 はてなでの思い出 サーバー管理・監視サービス「Mackerel」 出版社向けWebマンガビューワ「GigaViewer for Web」 マンガ家向けWebサービス「マンガノ」「ジャンプルーキー!」 ソフトウェアエンジニアとしての発信 退職を決意した理由 今後が楽しみ はてなでの思い出 社内でいくつかのプロダクトに関わらせていただきました。「Webアプリケーションエンジニア」という職種でサーバサイドやフロントエンドのコードを書いたり、TerraformやAWS CDKのコードを書いたり、時にはスクラムマスターやテックリードなどもしてきました。「はてなブログ」のような社名を冠したサービスには結局携わらないまま転職することにな
この記事はGetWild Advent Calendar 2016 3日目の記事です。 qiita.com 今回はGet Wild Slack Botを作りました。 作り方 コード 様子 注意点 まとめ 作り方 Google Apps ScriptでSlack botを実装する SlackのIncomingとOutgoingなWebhookを設定する 完成 コード だいたいこういう感じのものを書きました。変数名にWildやToughを使ったところよくわからない状態のままバグったりして困ったので、一般的なコードを書くとき変数名はちゃんとしましょう。 var INCOMING_WILD_URL = 'https://hooks.slack.com/services/hoge/fuga/piyo'; var WILD_USERNAME = 'getwildbot'; var WILD_ICON_
たとえばGoで書かれているプロダクトのCIをGitHub Actionsでやっていて、Goのバージョンがあがるたびにこのファイルを毎回ちまちま更新しているとあまり面白味のない作業になってしまう。最近だとGo 1.18 から 1.19 にあげるときに以下の go-version に書いてる数字を 1.19 にあげる必要があった。 steps: - uses: actions/checkout@v3 - uses: actions/setup-go@v3 with: go-version: 1.18 - run: go version actions/setup-go@v3.1.0 からは go-version-file に go.mod のパスを指定することによってそこからバージョンを取得して使ってくれるようになった。便利。 .go-version にも対応しているようです。 github.
我々も「スクラム」やるぞ!と言われても、イマイチどうしてスクラムでやりたいかが伝わっていないことがあると思います。あまり乗り気でない開発者は以下のようなことを感じているかもしれない。 スクラムを導入したところで嬉しさがわからない スクラム独自の用語が沢山あり、覚えるべき概念が多そうに感じる・学ぶための労力が割にあわないと思っている そもそもチーム改善とかに興味がない 改善に興味がなかったら厳しそうですが、スクラムを導入する嬉しさは簡単にでも紹介できたほうが良いと思うのであらためてちょっと整理してみます。 そもそもどういうことができているチームが優秀なチームかというのを考えると 以下のようなことができていると、優秀なチームなのかなと私は考えています。 改善サイクルが回っている(一定の周期で開発と振り返りと改善を繰り返すことができている) タスクが急遽差し込まれたり、方針が変わったときにスムー
こんにちは!現在はてなのMackerelチームにてアプリケーションエンジニアをしています、 id:stefafafan です。今回はMackerel Advent Calendar 2016 10日目の記事として、オフィスの環境改善でMackerelを利用したことについて書きたいと思います。 qiita.com 前日は id:ariarijp さんの「mackerel-client-goを使ったBotを作る」でした。 ariarijp.hatenablog.com もくじ オフィスの環境を改善したい netatmoウェザーステーション 実装 データの取得 Mackerel, Slackとの連携 Google Apps Script GASでやる際の注意点 GASの便利概念 コード 測定値の取得 Mackerelへ投稿 Mackerelの設定 監視設定 チャンネル設定 通知グループ アラート
id:Songmu さんの以下のエントリを読みました。自分も読んでいて共感できるところあったので、はてなブックマークのコメントに一瞬書きかけたけど、せっかくならブログに書こうと思い書いてみます。 songmu.jp 自分の性格 自分は元々上昇志向がある方だと思う。難しい議題に挑戦してコツコツとがんばった結果良い成果を出せるような人間だと思っている。というかそうであると自分自身勝手に期待している。 あと、自分は常に勉強とか仕事とかで中の上以上にいる、もしくはいるべきだと思ってしまっている。常にというのは、学生時代から社会人になったいまもという意味。 一方で何かが上手くいかなかったらわりと自分自身が責任を感じるし、周りのメンバーが滅入ってると自分も滅入る。 苦しかった事例 高校生時代*1は、元々中学オール5でやってたので勉強に自信があった自分が、段々勉強が難しくなって文系科目で成績を落とし始め
こんにちは、私は日々SlackやScrapboxを仕事で利用していますが、ふと自分の気をつけポイントをまとめておこうと思ってこの記事を書きました。 主にScrapboxを使ってるときの話をしますが、ツールに限らない話題だと思います。以下のエントリのお二人と同じチームに現在所属しています。 medium.com Scrapboxとは: scrapbox.io 前提 まずチームでScrapboxをどう使っているかというと、 職種によらず、Webアプリケーションエンジニア、iOS/Androidアプリエンジニア、デザイナー、企画、ディレクターなどなどみなさん使っています 定期的に開催している会の式次第、議事録、新機能作る際の要件整理、タスクの洗い出し、日報、などわりと何でも書いてます 情報の種類 何でもかんでもまとめているうちに、そもそも「情報」にはいくつかの種類があると気づいたので、以下のよう
同僚のこういう記事を読み、そういえば自分もWeb系の企業に入ってから初めてデータ移行の流れとかを知ったなーとなったのと、せっかく技術ブログあるのにあまり書いてないのは勿体無いなーという気持ちからこの記事書いてみます。 www.yasuhisay.info 技術系の記事はもっと気楽に書いていきたいマン。 何がしたいのか 流れ どういうことか ほか 何がしたいのか 何らかの理由でデータベースの構造を変えたいとなった際、いきなりガバッと変えたいのもやまやまですが、動き続けているWebサービスだとそれはちょっとできないですよね。いきなり画面がみれなくなった!いきなりログインできなくなった!とかなると大変です。また、いじっている間に何かしらのミスでデータが飛んじゃって前の状態に戻せなくなるとか。Webサービスは出してから後々のリリースで修正を入れることは確かにできますがそれがデータベース層での変更で
このエントリははてなエンジニアAdvent Calendar 2021の10日目の記事です。今回はVisual Studio Code向けの拡張を作った話を書きます。 拡張の様子 はてな記法そこそこ使っている 自分ははてな社員というのもあり、自社のサービスをちゃんと使っておきたいという気持ちで個人ブログもはてな記法モードで書いています。 ただ普段コード書くときはVS Codeで書いており、VS Codeは現状はてな記法で書かれた文章は認識してくれないので、中々手元で書くモチベーションがあがらない。 また、VS Code拡張作ってる人々が周辺にいたので自分も作ってみたいかもと数日前に突如思い立ちました。 ということで作った 作りました。いますぐインストールしましょう。 marketplace.visualstudio.com ソースコードはこちらです。 github.com 見どころ 見どこ
業務で監視にMackerelを使っているのですがここ最近も機能が増えたり、実際使っていく中で閾値の設定などでどうするんだっけと迷ったりしたことがあったので、自分の理解のためにもまとめてみようと思います。 ここでは主に以下のことについて書きます。 監視と通知の違い 監視の閾値設定 通知のミュート mackerel.io 「監視」と「通知」は別 「監視」 基本のWarningとCriticalの閾値設定 「平均値監視」と「アラート発生までの最大試行回数」 ダウンタイム 「通知」 通知チャンネル アラートメール通知受信設定 通知グループ アラートの再送間隔 監視設定のミュート オーガニゼーションに関わる全ての通知のミュート まとめ 監視や通知の微調整がしたいときにやれること 監視や通知を一時的に無効にしたいときにやれること 「監視」と「通知」は別 まず、監視と通知は似ていますが別の概念です Ma
OSSへのちょっとしたコントリビューションに成功したので、どういう流れでコントリビュートしたのかブログに簡単に流れをまとめてみようと思います。OSS活動してみたいけどどういう流れでやれるのか気になっている方の参考になれば幸いです。なお今回の修正Pull Requestはこちらです。 github.com 経緯 GitHub App の権限で Songmu/tagpr を利用する - stefafafan の fa は3つです とかにも書いたのですが、個人的に作ったライブラリにこちらの Songmu/tagpr を導入したら便利になったので、そのままはてなで運用している以下のリポジトリとかでも使ってみてはどうかとブログチームの方に紹介しました(自分はブログチームではないのですが、Slackの雑談チャンネルでおもむろに紹介しました)。 github.com このあと軽くウォッチしていたら、なぜ
こんにちは、すてにゃん (id:stefafafan) です。こちらはコミュニケーション Advent Calendar 2016 8日目の記事です。 qiita.com 今回はテキストコミュニケーションについて書こうと思います。 テキストコミュニケーションとは テキストでやりとりするときと実際に会話するときの違い 相手の状態がわからない 感情が伝わりにくい ねこ 「にゃーん」を使う場面 「にゃーん」するメリット まとめ テキストコミュニケーションとは テキストコミュニケーションとは文章を使ってのコミュニケーションで、例えば私はWebエンジニアなのですが、仕事の間結構な時間テキストでやりとりをしています。テキストでのコミュニケーションと実際に対面して声を発するようなコミュニケーションは結構いろいろと違うなとここ最近感じはじめました。 テキストでやりとりするときと実際に会話するときの違い 実
2017年に以下の記事を書いていました。最近も時々この記事が引用されたりX (Twitter) でもいまだにシェアされたりしているのを観測しています。 blog.stenyan.jp なおこれはもはや7年前の記事で、ベースの考えは大きくは変わっていないものの、普通に自分用のチャンネルをいまは作っています。 運用次第で良し悪しある まず結論としては、チャンネルを作ったほうが良いとか作ってはいけないということよりも、使われ方(運用)方法次第で上手く回らない可能性があるよねという話だと思っている。なので、Xなどでtimes不要論が流れてきても「結局どう運用しているか次第だな〜」とニュートラルよりな気持ちで静観している。 例えば以下のような運用の場合はひょっとすると見直した方が良いかもしれない。 チームのチャンネルでは基本的に何も書かずに、自分の分報に仕事に関する考えや思いを書き続けている→チーム
Go言語のドキュメントに掲載されているソースコードをみると、コメントが緑色になっている以外シンタックスハイライトが特にないことがわかる。 例えばブログの記事はこんな感じ。 blog.golang.org base64.goのソースコードとかを見るとこんな感じ。 golang.org 調べてみると、「シンタックスハイライト足しませんか?」という提案が何度かあったがどれも断られているようだった。 議論の様子 golang-nutsというGoogle Groupsのグループ (誰でも参加できる) で2012年にGo Playgroundにシンタックスハイライト足しませんか?という提案のスレがあった。 Rob Pike氏なども登場している。ざっくり読んだ感じ、「Go言語はシンタックスハイライトなくても十分読めるし不要だろう」みたいな流れ。 groups.google.com Redditでも同じこ
現在はてなのMackerelチームにてアプリケーションエンジニアをやっている id:stefafafan です。先日私のチームに id:Soudai さんがジョインしました。まだまだ入社して間もないのですがチームメンバーだけでなく、会社の色んな方と打ち解けているのを感じててすごいなと思っています。彼のこの記事を読んでとても良いなと感じたので、私は逆に新卒2年目の目線で自分が気をつけてる事を書いていこうと思います。 soudai.hatenablog.com 相手のことを知る コミュニケーションや文化 メンバーとの交流 あとがき 相手のことを知る 学生時代と違って社会人になると仕事をしている時間の割合はとても多いので、一緒にお仕事をするならばある程度相手の事を知りつつ楽しくやっていきたいなと個人的には思っています。なので基本的にチームや会社に新しく社員が入るたびになるべくお話をして、共通の趣
Go言語でsliceの重複排除について書きます。Go 1.21前提です。 slices パッケージを使っての重複排除 Go 1.21から slices パッケージが増えました。ここに生えている関数を利用して重複削除のコードが書けます。 pkg.go.dev 例えば int の slice の重複排除は以下のように書けます。 integers := []int{1, 2, 2, 1} slices.Sort(integers) // [1 1 2 2] uniqValues := slices.Compact(integers) // [1 2] slices.Compact は連続する値を1つにまとめる関数なので、重複排除したい場合は slices.Sort で先にソートする必要があります。 User という struct の slice を id で重複排除したい場合はどうすればいいかと
現役はてな社員ということもあり、ドッグフーディングの意味も込めてずっとはてなブログを利用してきました。ブログを書く時は基本はてなブログの記事編集画面から直接編集してきましたが、このたび公式でGitHubテンプレートリポジトリが公開されていたので使ってみることにしました。(自分ははてなブログチーム所属ではありませんが、株式会社はてなのエンジニアなので宣伝記事ではあります)。 staff.hatenablog.com セットアップについて 基本的にリポジトリのREADMEに書いてある通りぽちぽちしていれば簡単に記事を全部リポジトリに同期できて非常に楽でした。記事の同期の際に下書きエントリも公開状態になっちゃうのかと少し気になりましたが、そこは初期セットアップの際に下書きも取り込むかどうかのフラグがあったので安心ですね。 github.com なお、自分はWebアプリケーションエンジニアであり日
次のページ
このページを最初にブックマークしてみませんか?
『stefafafan の fa は3つです』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く