WebAssemblyに特化したプログラミング言語「MoonBit」のコンパイラが、GitHubで公開されたことを、開発元である中国広東省深セン市にある研究組織「International Digital Economy Academy (IDEA)」が発表しました。 Today is the day! The MoonBit compiler is now publicly available on GitHub! After 2 years of private development, we’re ready to build an open, collaborative community around MoonBit.https://t.co/M8y3e9rkn2 pic.twitter.com/BbJRLf7Vnm — MoonBit (@moonbitlang) Decemb

けんけん@リツアンSTC @nekomimi999 沖縄出身、関東在住　30代　エンジニア10年目 最近は顧客調整ばかりのエンジニア 取得資格：FE/AP MBTI：ENFP リツアンで働いてます～もし興味があれば 以下のURLからエントリーしていただくと喜びます ritsuan.com/lp/2023/07_2/?… けんけん@リツアンSTC @nekomimi999 技術技術ばっかり言ってるエンジニアと自分が合わないのは 「で、それで会社にいくら金が入ります？」 という考えが自分にはあって相手にはないからなのかね？ 端的に言うと、あなた1名が稼ぐお金より中堅エンジニアを3名増員して稼ぐお金のほうが多いし、コーディングよりも要件定義できる人のほうが単価は高くなるからねえ。 この考え、そんなに間違ってない気がするんですけどねえ 2024-12-22 07:22:15

マネージャーになると、1on1や評価のタイミングで期待を伝える一環として誰かにフィードバックする機会が増える。マネージャーになって初めて誰かに明確にフィードバックするという経験をする人は多いと思う。自分もそうだった。 今思うと、マネージャーになる前にフィードバックの練習をする機会は色々あったと感じる。自分がもっと意識してやっておけばよかったと思いつくものをざっと書き出してみる。 チームの振り返り 対個人ではなくとも、自分がよかったと感じたこと、問題だと思っていることを言葉にして伝える練習になる チームにもよるけれども、できるだけ積極的に意見を出し、伝え方のレパートリーも増やしていけるとよい アンケート回答 人事施策やイベントごとなどでアンケートを求められた時に、きっちり答えるようにするのもよい練習になる よかったことや改善してほしいことを相手に伝わるように言葉にするのは、慣れないと難しい。

50代のおっさんエンジニアになってたので、雑に40代にやっておいてよかったことなどを振り返ってみた。思い出補正があるかもしれないので参考にしようとする人は注意。 運動習慣をつけた 資格学習を継続した 読書習慣を維持した 仕事と関係ない勉強を始めた IT勉強会コミュニティへの参加をやめた ブログを書き続けた 運動習慣をつけた 40歳になったころに人間ドックでメタボ判定を1度受けたことをきっかけに、運動をするようになった。現在も続けているので習慣化に成功しており、おおむね健康を維持できている。 ゴルフを含めてスポーツの趣味はない（今もない）。ゴルフは誘われるけど、興味がない（週末に会社の人と遊ぶような思考を持ち合わせていない） ダイエットするなら食事改善というのは理解しているけど難しそうなので、筋肉つけて代謝を高める方向性を選択 コロナ禍以前は会社帰りに福利厚生で安く使えるジムのプールで泳いで

はじめに この記事はLipersInSlums Advent Calendar 2024 「スラムで年収をあげる〜だが僅かばかりの友の他は、皆、スラム民を嘲った。資格取得で年収アップに挑むなどと〜」の大遅刻組の記事である。シモンは泣いていい。 筆者がプログラミングを初めた頃はインターネットの検索技術は発達しておらず、良質なコンテンツにたどり着くには一苦労だった。そのため、何か新しいことを学ぶのに最初に手を取るのは技術書であった。 今では検索技術は高度に発達し、必要な情報は検索すればたちまち手に入る用になった。しかしながらそれらの断片的な知識群を体系化し、習得するのは未だ難しい。体系的に知識を習得する上で技術書は未だ最も有力な候補となる。 この記事では主にジュニア(?)エンジニア向けに、読むとプログラミングに必要な比較的陳腐化しにくい様々な知識が体系的に身に付いて役に立つお得な技術書を簡単に

※この記事は、2024 Speee Advent Calendar 22日目の記事です。 前日の記事はこちらになります。 tech.speee.jp はじめに 初めまして、2022年度新卒でSpeeeに入社し、現在Housii（ハウシー）という完全会員制の家探しマッチングプラットフォームの開発チームでエンジニアをしている大金と申します。 今回は、自分の実体験を元にした記事を書いてみました。 開発物を日々沢山リリースしているものの、イマイチ「事業の成果」に向き合えていないと感じるエンジニアの方々にとって、少しでも今後の動き方の参考となる記事になれば幸いです。 目次はこちら はじめに なぜか「事業成果」から遠ざかってしまう問題 「価値ある顧客体験」を軸にした成果定義へのアップデート 1. 事業の解像度の向上 2. 施策のプランニング周りの動きの改善 3. 「見るポイント」の変化 「事業成果」に

TL;DR 令和に踏み台サーバーを作成する Amazon Linux 2023AMIとSSM Agentを利用したEC2 証跡を取得する About EC2とSSMのセッションロギングを使用して証跡を取得することが目的。 ECS/Fargateでも同様のことが可能ですが、SSM AgentがプリインストールされているAMIのEC2を使い捨てる方が運用コスト的や構築コスト的に楽なためEC2を選択。 How To アーキテクチャ Instance Profileの作成 assumerole.json $ cat <<EOL > assumerole.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action

SNSなど、ユーザー名をURLに含めているサービスは色々ある。このZennもそうだ。ただ、考えることが多い。例えば以下の点だ。 システムで使いたい文字列をユーザー名に使われる可能性があるので、ユーザー名に使えない膨大な文字列のリストを管理する必要がある 実装に失敗すると、一部のユーザーだけ特別扱いするルーティングを独自実装する必要が出かねない 簡単な対応策としては /user/{ユーザー名} のようなURLの規則にすること これを採用しているサービスもあるが、見た目がダサいからか、あまり好まれていない印象がある ということで、現実的な解決策として @user_name みたいな@始まりのURLにする方法がある。 自分が知る限り、最初にこれをやったのはMediumだが、Mediumは現在サブドメインにするルールになったようで、いつの間にかこの形式を辞めてしまった。 実はTwitter（現X）

コストと開発体験を両立させるfeature環境の運用方法この記事はニーリーアドベントカレンダー2024の20日目 その1の記事です。 こんにちは、SREチームの森原です。 今回はニーリーのfeature環境の管理方法について紹介していきたいと思います。 feature環境 feature環境とは、新しい機能やバグ修正を検証するために作業用ブランチを、インフラにデプロイしたものを指します。ニーリーではこのfeature環境の管理をPRのラベルで行っています。ラベルで管理することで以下のような利点があります。 特定のPRのみに対して簡単にfeature環境が作成・削除できる PRのラベルとライフサイクルに紐づいているのでfeature環境の立ち上げっぱなしを防ぐことができる feature環境とブランチの紐付きが明確で管理が簡単 以前のブログでSREチームの大木がfeature環境(主にバック

70点で始める業務効率化開発この記事はニーリーアドベントカレンダー2024の20日目 シリーズ2の記事となります。 こんにちは。グロース開発チームのエンジニアの西村です。 この記事では、事業成長に伴い増大しているオペレーションの効率化を目指した開発の一例について紹介しようと思います。 ニーリーでは、月極駐車場のオンライン契約サービスであるPark Direct(パークダイレクト)を展開しています。 パークダイレクトでは、ソフトウェアとオペレーションを組み合わせることで、管理会社様や借主様に価値を提供しています。そのため、パークダイレクトの機能は管理会社様や借主様だけでなく、オペレーションを行うニーリーの従業員も利用しています。 「ソフトウェアとオペレーションを組み合わせる」という点が、先日の記事↓でもあったようにプロダクトとして面白いポイントで、SaaSでありながらオペレーションの効率化が

はじめに LITALICO の @katzumi です。 2020 年に LITALICO へ Join して以来、ずっとレセプト業務の開発に携わってきました。 レセプト業務は複雑なドメインゆえミスが許されず、さらに３年に一度の大きな報酬改定があり、ロジックが大幅に変わります。 その改定作業は情報公開から実装完了までの期間が約 3 ヶ月と短いです。また、年々複雑化するシステムに対応する必要があります。 その複雑な業務に立ち向かった内容を過去にも以下の内容で開発業務の記事を書いていました。 今年 2024 年は法改正の年になっており、取り組みの結果、その後どうなったのか？を振り返っていきます。 今回も壮絶だった法改正 私自身の大規模法改正の経験が今回で 2 回目となります。 チーム構成としては私ともう一名を除いて前回の　2021 年度法改正を経験したメンバーがいませんでした。前回は 3 種類

GitHub Universe 2024 Recap in ZOZO https://zozotech-inc.connpass.com/event/336687/

インターネットのオタクたちがツイッター2（ツー）とか言って遊んでいる間に、マジで冗談みたいな名前のSNSが誕生していた。その名もmixi2である。昨日の昼頃、僕のTLに突如として招待リンク付きの投稿が舞い込んだ。最初はジョークサイトかなにかだと疑っていたが現に実用可能なアプリケーションが存在している事実から、紛れもなくあのmixiの後継サービスが生まれたのだと理解した。 2006年、フレッシュな中学1年生だった僕はある時、個人サイトのような独立した形態ではなく、かといって匿名掲示板のように誰でも書き込めるわけでもない特殊なWebサービスがあることを知った。いわゆる招待制サイトに属しているが、しかし何百万もの人々がすでに利用していると言う。それはもう2年前から始まっていて、自分はいつの間にか出遅れていたのだ。 さっそく情報を収集する――mixi――名前が読めない――ミクシーと呼ぶらしい――と

この記事で書きたいことは、大体以下のようなことです。 ・「タスクを実行する能力」は大事ですが、「タスクを適切に振る能力」もとても大事です ・「タスクを振るのが苦手」という人は、かなりのベテランでも珍しくありません ・管理職になった頃、私も「タスクを人に振る」ことが大の苦手で、しばしば自分で仕事を抱え込んだり、タスクを偏らせたりしてしまっていました ・「タスクの意味や優先順を明確に言語化出来ておらず、タスク振りに説得力がないこと」が最大の原因だったと思っています ・解決する為に、「タスクを徹底的に言語化すること」「誰にお願いするか、その理由も明確化すること」「それをチームで共有すること」などを習慣化しました ・その結果、以前よりはだいぶマシなマネジメントが出来るようになった気がします ・言語化大事ですよね。今後も精進します 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書い

※この記事は、2024 Speee Advent Calendar14日目の記事です。 昨日の記事はこちら tech.speee.jp はじめに こんにちは！2023卒で入社し、今はイエウールという自社サービスのWebサービスの開発をしている、木俣と申します。周囲からはきまっちゃんと呼ばれています！この記事が、「Speeeのエンジニアになると「開発」の他になにができるようになるか」知りたい方に届くと嬉しいです。 突然ですが、Speeeでは、働くうえでの指針となる15のカルチャーが存在しています。 Speee Style - 株式会社Speee これは、Speeeメンバーが持つ共通の価値観であり、これを深く浸透させるため毎朝数人が自分なりのカルチャーの解釈と体現している人を発表します。ありがたいことに、仕事で関わった幾人かのチームのメンバーからこのカルチャー発表で、次のようなことを褒めていた

こんにちは、ファインディでFindy Team+の開発をしている古田(ryu-f)です。この記事はFindy Advent Calendar 2024 15日目の記事です。 adventar.org ファインディでは主にバックエンド領域の開発を担当していますが、エンジニアのキャリアのスタート地点は実はフロントエンドでした。ファインディにジョインするまではバックエンドの経験は皆無です。 今回はそんな私がなぜバックエンドに挑戦したのか？どのような過程を歩んできたのか？実際に他職種を経験してみてどうだったのか？などファインディにジョインしてからの約4年間をふりかえりながらお話出来ればと思います。 なぜバックエンドに挑戦したのか？ バックエンドに挑戦したことで得た学び やらないことを決める 試行錯誤を高速で繰り返す 何も分からないからこそスコープを絞る バックエンドを経験してみてどうだったか？ ド

こんな経験はありませんか？ 「開発メンバーになんでこれ優先度高い/低いんですか？」と聞かれるとき 「考えていた新機能以外にビジネスサイドからの要求が尽きない。ユーザー要望は待ったなしで、技術的な課題も放置できない……。どれから手をつければいい？」と思うとき はじめまして。株式会社GaudiyでPdMをしている三島(@kaa_a_zu)です。今は漫画やゲームのIPごとにファンコミュニティを作ることが出来るFanlinkというサービスを作っています。 実際、私も優先順位で悩んだことが何度もあります。多くの要求やアイデアに囲まれたとき、どれを先に取り組むべきか判断するのは簡単ではありません。 今回の記事ではこの課題を打破する一つの手段として、今回はICEスコアをベースにした優先順位づけの方法を紹介したいと思います。 スコアリングによる初期整理、そしてスコア化だけでは拾いきれない部分を対話や情報共