市⾕ 聡啓 Ichitani Toshihiro 新価値創出、組織変⾰の伴⾛⽀援 (株式会社レッドジャーニー) ・チーム、事業、組織に「アジャイル」を取り⼊れ、向き合う伴⾛⽀援 ・新規事業開発、プロダクト開発の⽀援(仮説検証型アジャイル開発) 特に専⾨は 「仮説検証、アジャイル開発、組織アジャイル」 Toshihiro Ichitani All Rights Reserved. 2
概要 pythonでテストコードを書くときがありますが、(筆者のように)超初心者からすると難しい用語や書き方がたくさん並んでいてハードルが高いです。 テストコードの入口となる最低限(最低限過ぎるかもしれませんが)の書き方を備忘を兼ねて書きます。 pythonでのテストコードを書く時のライブラリの種類 筆者が簡単に調べたところ、2つのライブラリがよく使われているようです。 unittest : python標準ライブラリ。インストールが必要ない。pytestと比較すると、柔軟なテストケースを書きづらい。 pytest : サードパーティ製のライブラリ。インストールの必要がある。柔軟なテストケースが書ける。pythonのテストコードを書く時のデファクトスタンダートになりつつある模様(これが本当かは確認していないですが、そういう記述を見かけることが多かったです)。 筆者個人としては、以下の3つの
2024.05.21 スキル 「つまりどういうこと?」「要するにできるの、できないの?」「それって何の話だっけ」 技術的にどうするべきか正解は見えているのに、頑張って説明しても返ってくるのはそんな言葉ばかり……。「うまく伝えられない」という悩みを抱えるエンジニアは、少なくないのでは? 2023年のITエンジニア本大賞・技術書部門で大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』(技術評論社)の著者であり、SNSでの情報発信やイベント登壇でも活躍する「言語化のプロ」であるミノ駆動さんも、昔は「君が何を言ってるのか分からん」と上司に言われていたそう。 ミノ駆動さんはどのように言語化能力を伸ばしたのか。聞くと、出てきたのは「合意駆動」というキーワード。その正体とは? ミノ駆動さん(@MinoDriven) 新卒でNEC の関連会社に入社。その後キヤノンでの10年のエンジニア経験を経て、We
2020/7/8 ビデオSaaSのエンジニアリング最前線の登壇資料です。 WebRTCを学ぶための指針についてまとめています。
組織に“できたてホヤホヤの暗黙知”をシェアする仕組みをどうつくるか?子どもの「逆上がり」習得過程を見て気づいたこと 今日は「子どもの日」ということで、個人的な話になりますが、先日、5歳の娘が「逆上がり」を習得しました。 一人の親として感動を覚える瞬間だったことはもちろん、習得のプロセスがまさにヴィゴツキーの言う「ZPD(Zone of Proximal Development、最近接発達領域)」そのもので、親としても、研究者としても非常に感激してしまいました。 そこで本記事では、「娘の『逆上がり』習得」というきわめて身近なエピソードを通じて私が感じた、ナレッジマネジメントにおける「できたてホヤホヤの暗黙知」の重要性と、「ZPD」を学びにつなげるためのポイントについて、書いてみたいと思います。 ある日の公園での「驚き」の出来事ある日、保育園の帰り道に寄った公園にて。5歳になったばかりの娘が、
# 参考資料 - https://speakerdeck.com/pokotyamu/furikaeri-2024-95ceb97e-d587-4c4b-a4ec-5e52672644f6 - https://www.1101.com/umeda_iwata/ - https://speakerdeck.com/soudai/release-small
NEW! 2024.04.12 スキル 未踏落合陽一登大遊プログラマー 登大遊、落合陽一など数々のスーパークリエータを輩出してきた、独立行政法人情報処理推進機構(IPA)の「未踏IT人材発掘・育成事業」(以下、未踏IT)。その立ち上げから現在までを知るのが、統括プロジェクトマネージャーの竹内郁雄さんだ。 2017年には、ビジネスや社会課題解決につながる人材を発掘する「未踏アドバンスト事業」にも統括プロジェクトマネージャーとして参画。国際的なデファクトスタンダードとなるソフトウェアを日本から生み出すべく、人材育成に心血を注いでいる。 前身の未踏ソフトウェア創造事業から数えて24年。のべ2000人を超える修了生を見てきた竹内さんだから言える、優れたエンジニアに共通して求められる素養を聞いた。 未踏事業統括プロジェクトマネージャー(PM) 一般社団法人未踏 代表理事 竹内郁雄さん 1946年、富
概要 この記事は、OpenTelemetryについて全く知らない人に向けた入門記事です。前半でOpenTelemetryとは何か解説し、後半でデモアプリケーションを動かしながら、理解を深めていきます。 この記事の執筆時点のOpenTelemetryの最新バージョンは、1.8.0です。参照する公式ドキュメントや動作確認するデモアプリケーションのバージョンも1.8.0です。 OpenTelemetryとは OpenTelemetryは、マイクロサービスアーキテクチャーで分散されたサービス(アプリケーション)の健全性や性能を示す「テレメトリーデータ」を生成、収集、管理、エクスポートするためのOSSです。 大規模な分散システムでは、健全性や性能を把握することが極めて困難なため、迅速なトラブルシューティングのためにはテレメトリーデータの収集が求められます。分散されたサービス(アプリケーション)からテ
<この記事の著者> ヨス - Tech Team Journal 業務効率を改善し、タイムパフォーマンスを高める時間最適化の専門家。「単語登録」の便利さを伝える「単語登録エバンジェリスト」。 「タスク管理」という言葉は知っている人が多いかもしれません。では「タスク管理について説明してください」と言われたらどう答えますか。 おそらく「やるべきことを書き出し、タスクを細分化し、いつやるかの期限を決め、その日に必ず遂行する」のような定義が思い浮かぶでしょう。 効率化の書籍を出版しているほど「タイムパフォーマンス」にこだわるわたしですが、実はタスク管理は苦手でした。 なぜなら、一般的にいわれる「タスク管理」の手法がわたしには向いていなかったからです。 【目次】 なぜタスク管理ができないのか? その日だけにフォーカスし「着手」を目的とする 実績はウソをつかない なぜタスク管理ができないのか? タスク
この記事は? 著者は、エンジニアにとって最も大事なものの一つは契約であると考えます。なぜなら、契約によって我々はお金を得ることができ、労働対価を受け取って生きていくことができるからです。プロジェクトにおいてトラブルが発生すると、契約はメンバーを守ってくれるものになります。したがって、雇用契約、請負契約、準委任契約など何の契約であっても隅々まで確認し、不利にならないようにしないといけません。社員であれば誠実に職務に向き合う必要があります。請負契約であれば対価を得るために納品する必要がありますし、準委任契約であれば善管注意義務を背負いプロとして日々業務を行なっていく必要があります。一方で、著者は長くにわたって業務委託契約でパートナーとして参加してくださっているエンジニアたちと長らく協働してきた経験がありますが、ユーザーとしてもベンダーが妨害要素なく働けるように、協力義務を果たす必要があります
こんにちは!Dev Branch で Engineering Manager をしている大坪です。この記事は Coporate HR 主催のは「明日をチョット良くする スキルうぉんてっどり塾」(internal) の第一回「業務コミュニケーションをサクサクにする研修」の資料として執筆した社内報を一部修正して作成しました。(ウォンテッドリー社員向け:社内報リンク) ざっくりまとめ コミュニケーションは丁寧さだけではなく内容をチューニングしよう相手が知りたいことを伝えよう相手が知りたいことを「相手の意思決定ロジック」から逆算しようはじめに今回の研修では、業務コミュニケーションをサクサクにする方法について考えます。コミュニケーションの先には必ずコミュニケーションの受け取り手に変化が生まれます。業務においてはその変化の中で特に重要なものに意思決定/行動があります。この2つをスムーズにして決めるべき
最近、『エンジニアのためのドキュメントライティング』という本を読みました。 非常にためになる内容だったので、本書であがったいくつかのポイントを私なりにまとめてみました。 また、エンジニアにとってのドキュメントは種類が多く、それぞれのニーズとそれに合わせたフォーマットも違うため、 良いドキュメントとは何か? を一概に述べることは難しいです。 個人的には、「ほぼ知識のない人が読んでも再現できる・解決できる」ということが大事なのではないかと思っています。 そこで、本記事ではドキュメントの範囲を少し絞って、想定される読者をエンジニア寄りに考えて書いています。ご了承ください。 目次 本記事では ドキュメントを作成する前 ドキュメントを作成する時 ドキュメントを作成した後 それぞれのタイミングにおけるポイントを挙げていきます。 📑 ドキュメント作成前のポイント フリクションログとは、あるユーザー1の
東京・立川を拠点に起業に関連したさまざまなイベントを開催しているStartup Hub Tokyo TAMA。本記事では、『「うまく言葉にできない」がなくなる 言語化大全』の著者で、伝える力【話す・書く】研究所の所長・山口拓朗氏が登壇したイベントの様子をお届けします。今回は、2つ目のテンプレート「結論優先型」について語られました。 前回の記事はこちら 「結論優先型」というテンプレート 山口拓朗氏(以下、山口):では、第3講にいきます。今日のもう1つのテンプレートで、「結論優先型」というものです。結論優先型はどんな流れで書くか。あなたが最も伝えなくてはいけないこと、結論。「私はこのアイデアに賛成です」も結論だし、「この商品をおすすめしたいと思います」も結論だし、いろんな結論の示し方がありますけど、とにかく結論が最初です。 そのあと、必ずセットで「理由」を書いてください。理由・根拠は論理的な文
職業柄、昔から人の「説明」を聞くことがとても多かった。 会社の現状、技術的な見解、商品のスペック、あるいは人の経歴についての話もあった。 そして、説明がとても上手な人もいれば、下手な人もいることを知った。 例えば、こんな具合だ。 「では、御社の事業説明をお願いします」 「わかりました、こちらが会社案内です」 「では、始めてください。」 「はい、では1ページ目をご覧ください。弊社の主要な株主は……全国に展開しており……事業所は……」 ……5分経過 「では次は、弊社の主要な事業です。おもに3つあり……」 「(退屈だな……後ろのページでも見ているか)」 ……5分経過 「次に今回お問い合わせの商品についてです……こちらの……」 「(その話はもうサイトで見たからいいよ……話ながいな……内職でもするか)」 ……5分経過 「以上となりますが、なにかご質問はありますか?」 「………いえ。」 例えば上のよう
この記事は Google Cloud Japan Advent Calendar 2022 初心者向け の 2 日目の記事です。 tl;dr 意外と簡単にコンテナをクラウド上にデプロイできる 環境構築不要でサクッと使える 試すときあまりお金がかからない Cloud Run とは Cloud Run とは、Google Cloud の製品群の一つで、HTTPリクエストで起動可能なステートレスコンテナを実行することができるマネージドコンピュートプラットフォームです。Cloud Runはサーバーレスなため、インフラ管理の必要が最小限になり、優れたアプリケーションの構築に集中することができます。 実際にやってみたいのは山々だが… 実際にやってみよう!と思っても、やはり環境構築で二の足を踏んでしまったり、自分のローカル開発環境から、どうやったらクラウドに接続したらよいか、認証認可はどうしたらいいのか
この記事は Google Cloud Japan Advent Calendar 2022 の 13 日目の記事です。 2022 年は本番環境で Cloud Run を利用した事例を良く見た 1 年でした。新機能のリリースだけでなく、CPU やメモリの選択肢が増えたのも印象的です。 ところで、Cloud Run を構築するのに、何を使っていますか?gcloud CLI でデプロイする、または、Terraform で定義して CI 環境から実行するのも、管理がしやすく良いと思います。 一方、初めて Cloud Run を触る時や、細かいオプションを確認したい時など、コンソール画面で操作するのも見やすくて良いですね。 ということで、今回は Cloud Run コンソール画面でサービスを作成する際の設定項目を 1 つずつ解説していきます!Cloud Run にはバッチ用途のジョブ(Cloud R
はじめに こんにちは、shirakiです。 昨年10月にはGoogle Cloud Next が開催され、Google Cloudも盛り上がりを見せております。 今回は「まずは使ってみよう!」ということでGoogle Cloudの事始めとして、初期セットアップからcloud Runの簡単なチュートリアル実施までをご紹介いたします。 なお、2022年12月現在時点で $300 分の無料クレジット※が付与されます。アップグレードするまで料金は発生しないためこれを機にGoogle Cloudを始めてみましょう。 ※無料クレジットには90日間の有効期限がありますのでご注意ください。詳細は[こちら]をご確認ください。(https://cloud.google.com/free/docs/free-cloud-features#free-trial) この記事について 対象者 Google Cloud
せっかくFlutter大学に入学するまたは教材を利用するのであれば、思いっきり使い倒して欲しいと思っています。 ということで今記事では、「Flutter大学を使い倒して、未経験からFlutterエンジニアになるためのロードマップ」を紹介したいと思います。このロードマップは私の勝手な妄想ではなく、2015年8月にモバイルエンジニアを始めた私が、2020年4月からFlutter大学を運営し、KADOKAWAドワンゴ情報工科学院のFlutter講師も半年経験した上で、実際に効果的だった方法 をベースにしています。 以前以下のような記事も書いたので、重複する所もあるとは思いますが、今記事では選択肢を複数与えず、これとこれをやれ!と断定していきたいと思います。その方が迷いなく進めると思いますし、正直内容には自信があります。問題はやるか、やらないかです。 ① Flutterに慣れろ まずはFlutte
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く