皆さんはアプリケーションの Tracing を行っているでしょうか。 巷には GCP の Cloud Trace, AWS の X-Ray, Azure の Application Insights など関連するサービスが溢れています。 ここでは、Tracing を導入する手段として OpenTelemetry と Go での実際の導入方法について、簡単に紹介させていただきます。 想定読者 Go で Tracing に興味がある方 OpenTracing, OpenCensus を既に使用していて OpenTelemetry への移行を検討している方 Tracing を導入したもののベンダーロックインされていて、課題を感じている方 OpenTelemetry 概要 実際に Tracing を導入した方は分かると思いますが、Instrumentation (計装) という作業を行う必要があり

こんにちは、unnameの代表取締役の宮脇啓輔です。 普段から重要だなと感じたことや、自分なりに思考したものを伝えようとXで投稿しているのですが、その中でも反響が大きかった投稿をさらに肉付けして発信しようという試みで記事化しております。 「頭の回転が速い」とは「累積思考量が多い」ことだと思います。「過去に似たようなテーマについて考えたことがある」から、すぐに自分の意見が出てくるし、回転が速く見える。考えたことがないと、その場で思考してしまい、遅く見える。そういうことだと思っています。… — 宮脇 啓輔 / 積極採用中 / unname (@keisuke_unname) March 21, 2024 この投稿がかなりいい反響をいただいたということもあり、投稿をベースに、もう少し肉付けして解説してみます。 「頭の回転が速い」の正体はなんなのか「頭の回転が速い」と見える人は、実際は「累積思考量

目的 Slackを使っていると、大抵どのワークスペースにも雑談や質問用のチャンネルが作られているかと思います。 チャンネル運営側からすると、そこで多くのエンジニアたちのコミュニケーションがとられることを期待しています。 しかし、結局は特定の人のみがたま～に使う程度になっていませんか？ その原因に「自分がチャットを投げてもいいのだろうか？」という心理的ハードルが大きく関わっていると思っています。 そこで、ここではSlackのワークフローという機能を使って匿名でチャットを投稿できるチャンネルを作ります。 なんちゃって掲示板みたいなものです。 ※Slackの有料プランが必要になります。 ワークフローとは 公式からの引用です。 ワークフローは、あなたとチームが Slack で毎日実行するタスクをやりやすくしてくれます。仕事の中のほとんどすべてのタスクやプロセスを、ワークフロービルダーツールで自動化

グラフィック系の開発者であるニキータ・リシッツァ氏が、「自身のプロダクトのあらゆる場所で使用している」と述べるお気に入りのテクニックである「指数平滑法」について解説を投稿しました。 My favourite animation trick: exponential smoothing | lisyarus blog https://lisyarus.github.io/blog/programming/2023/02/21/exponential-smoothing.html リシッツァ氏は下図のようなトグルボタンを例に解説を行っています。クリックすると「オン」「オフ」が切り替わります。まだアニメーションを何も設置しておらず、トグルボタンは左端と右端を瞬間移動しています。 機能的にはアニメーションが設定されていなくとも問題はないのですが、アニメーションを設定することでユーザーは何が起こって

サラダの旨辛たれ まずはサラダの旨辛たれ から食べていこう！！ 元祖旨たれに辛さを追加。絶対美味しい う、うまい……！！ 慣れ親しんだ旨たれのベースがありつつ、ピリッとした刺激が走る。夏休み明けにクラスメイトに会ったら「なんか雰囲気変わった？」って思う、あの感じの変化の仕方！！良さを残しつつ、全然印象が違う！うまい！ 真夏にビールと一緒に食べたい味！！いつもはサラダだけで食べているが、ご飯も欲しくなった。コチュジャンが入っているので、中華っぽさも感じる。 これは豆苗と炒めてもおいしそう！！ 作っちゃおう ちなみに味付けは旨辛たれのみ。味付けが楽……！！１分ぐらいで完成した。 そしてめっちゃうまい 無限にビールが飲める。この後記事を書かないといけないのでノンアルで我慢しているが、本当はビールと一緒に食べたかった。 これだけ豆苗と合うのだから、肉野菜炒めでも合うのでは？と思い追加で作ってみた。

＼スニダンを開発している SODA inc.の Advent Calendar 8 日目の記事です!!!／ 昨日は @KosukeSaigusa さんによる「Dart のドキュメンテーションについて」でした！ 明日は @toshiki-otaka さんによる「ISUCON13に参加しました！ (チームひろし)」です。 お楽しみに！ 導入 Go1.21で標準ライブラリとしては初の構造化ログのためのlog/slogパッケージが導入されました。 どういう設計や実装になっているのかに興味があったので調べてみると、パフォーマンスをかなり意識した実装になっていることが分かりました。 このブログでは、log/slogパッケージがどういう背景や目的を持って導入されたのか、基本的なAPIの使い方はどうなっているのか、また内部の実装でパフォーマンスが意識されているところはどこなのかをできるだけ詳しく解説したい

人の心に残り続けるゲームがある。 ゲームデザイナー上田文人氏の手掛けた『ICO』（イコ）と『ワンダと巨像』。その世界観と特徴的なゲーム性からゲームファンの間で長く親しまれるソフト。 今日はそんなプレイステーション2の名作ソフト『ICO』と『ワンダと巨像』が大好きな人たちと「いいよねえ……」と言う会を開きます。 開かねばならない。 参加するのはこの3人。 オケモト この記事を描いてるライター。ICOとワンダと巨像が好き。 ギャラクシー ジモコロ編集長。ICOとワンダと巨像が好き。 みくのしん オモコロ副編集長。ICOとワンダと巨像が好き。 今日はお集まりいただきありがとうございます！ みなさん話したくてうずうずしていると思います。 よっしゃー！ どっちも大好きよ！ 早く話させて～！！ 発売順に、まずは『ICO』の話からしていきましょう！ ※ここから先ゲーム『ICO』『ワンダと巨像』のネタバレ

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

Interactive GIF Music Video by AC-bu

全国で保育士の「一斉退職」が相次いでいます。 保育所などで複数の保育士が同じ時期に一度に退職してしまい、子どもの受け入れにも影響する深刻な事態です。 なぜこうした事態が起きているのか。 取材すると、慢性的な人手不足の中、職場環境によって今いる保育士の「やる気」や「志」が奪われている実態が見えてきました。 （社会部記者 小林さやか） 先月（3月）大阪・堺市の認定こども園で、運営法人の一部の役員によるパワーハラスメントなどの不適切な対応を訴えて、保育士のほとんどが一斉退職した件についてニュースで報じた後、NHKの情報提供窓口「ニュースポスト」には「同様の事態が起きている」と全国各地から多くの声が寄せられました。 ▽「半分以上辞める。けがや事故が心配」（自園で退職が起きた保育士） 「同じ様なことが起こっています。保育士が半分以上辞めます。園児に対する虐待と保育士に対するパワハラもある。少ない人数

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み　あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性　様々な努力をして、特に有効だったことを自分の本に書いたつもりではある

リンク JMOOC トップページ お知らせをもっと見る 講座ジャンルを絞り込み アート・デザイン 教育と学習 健康と医療 工学 コンピュータ科学 自然科学 社会科学（経済、コミュニケーション、他） 人文科学（心理、歴史、他） 統計・数学 ビジネスと経営 資格・試験対策 JMOOC企画講座（理工・情報・ビジネス系） AI活用人材育成講座（活用講座事例集、活用・理論講座） 講座配信プラットフォームを絞り込み gaccoOpenLearning,JapanPlatJaM 配信プラットフォームとは 講座状態を絞り込み 開講中募集中受付終了 さら 400 users 2889 JMOOC @JmoocSecretary 【カテゴリーについて】#JMOOC の講座はその内容や提供機関によって、下記の３つにカテゴライズされています。サイトトップの「さらに絞り込み条件を設定する」→「JMOOCカテゴリーを

つるかめ算の内容 つるかめ算とは、次のような問題です。中学入試、中学での連立方程式の問題、SPIなどで出題されることがあるので、見たことがある人も多いでしょう。 僕はこうした問題を見るたびに「足の数が分かってて、ツルとカメの数がわからないってどういう状況？」と思うのですが、そういうツッコミは今は置いておきましょう。 解き方はいろいろありますが、ここでは、連立方程式を使って解いてみます。ツルが $x$ 匹、カメが $y$ 匹いたとします（以下、両方とも"匹"で数えることにします）。合計で10匹いるので、\[ x+y=10 \]という式が成り立ちます。また、足の合計数が32本だとわかっています。ツルの足は2本でカメの足は4本だから、\[ 2x+4y=32 \]という式も成り立ちます。この2つが同時に成り立つので、 \begin{eqnarray} \left\{ \begin{array}{l

初めまして！ フリーランスライター／編集者のシモカワヒロコです。fabcrossでは、ライターさんの原稿チェックを担当しています。このたび、fabcross編集部から「電子工作の入門企画をやりませんか？」とお声がけいただき、この企画を持つことになりました。 私はゴリゴリの文系＆電子工作ほぼ未経験、おまけに超絶不器用です。でも、皆さんが楽しそうに工作している記事を読んで「やってみたい！」と思っていたのは事実。しかも昨年、共著「雑に作る」が話題となった石川大樹さんが一緒に作ってくださり、雑な電子工作の極意を教えてくれるとか！ これはやらない手はありません。 さて、私は無事に電子工作ができるのでしょうか？ ぜひ温かく見守ってくださいませ！ 作る人…シモカワヒロコ フリーランスライター／編集者。東海地方の出版社に勤めたのち、ロボット工作教室を運営する企業に全くの未経験で転職。小学校低～中学年の子ど

不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会

おことわり 最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。 また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。 なぜこの記事を書いたか チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしま