「Docker Dev Environments」発表。Dockerコンテナを使ってコードと同様に開発環境をバージョン管理、共有、再現可能に
「Docker Dev Environments」発表。Dockerコンテナを使ってコードと同様に開発環境をバージョン管理、共有、再現可能に Docker社は、アプリケーションプログラマがソースコードのバージョン管理をGitHubを用いて行うように、Dockerコンテナを用いて開発環境のバージョン管理や共有、再現などを簡単に行える「Docker Dev Environments」のテクニカルプレビューを発表しました。 Today we are releasing a preview of Docker Dev Environments. Learn more in this blog post from our very own @Nebuk89 https://t.co/W3YTMewZyR — Docker (@Docker) June 23, 2021 現在、複数のプログラマが所属す
はじめての「簡単なお仕事」は簡単ではない。 - MonotaRO Tech Blog
モノタロウでスマホアプリを担当しているuw_shioです。 今回は増員をしていった結果、各自がそれぞれ頑張るようなチームとなってしまった状況から、ペアワークをきっかけに、ペアプロ、モブプロが文化となってチームとしてワークできるようになったお話をします。 組織の規模が拡大していく過程において、属人化された業務を個人単位で行う働き方から組織としてワークする形へのシフトは避けて通れない道となります。そんな時に悩みの種となりやすいのが、業務の属人化やメンバーの育成ではないでしょうか。 部下や後輩に新しい業務を引き継ごうとしても時間がかかり上手くいかない、そんな経験ありませんか？私は過去に何度もありました。 例えば、アフリカーンスなど未知の言語を習得するというタスクをアサインされたとしたら、何から始めて良いか分からず漠然とした不安を感じるのではないでしょうか。新しいこと、とりわけ新しい業務に対しては
Google 公式ウェブ開発者向けリソースのご紹介
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
NTT Com オンボーディングハンドブック
オンボーディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したオンボーディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/onboarding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『オンボーディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したリモートワークハンドブックや、チームビルディングのプラクティスをまとめたチームビルディングハンドブックも参照ください。 読み始める #こちらから本編に進めます。 はじめに
現役高校生が、AtCoderでレッドコーダーになるまでにやってきたこと。プログラミング上達の秘訣を全て教えます - Findy Engineer Lab
こんにちは、はじめまして。筑波大学附属駒場高等学校 3 年生（今年 4 月から東京大学に入学予定）の米田優峻（@e869120）と申します。私は競技プログラミング（競プロ）が趣味で、AtCoder・情報オリンピック・パソコン甲子園などの大会に出場しています。2021 年 3 月時点で、AtCoder では赤色（レッドコーダー）です。また、国際情報オリンピックの 2018 年／2019 年／2020 年大会で金メダルを獲得しています。*1 とはいえ、決して簡単にこの記録を手に入れられたわけではありません。何度も挫折と失敗を経験しながら自分のスキルを磨いた結果、競プロを始めてから 3 年後にはレッドコーダーになることができたのです。 今回は「わたしの選択」というテーマで寄稿の機会を頂いたので、私が中学 1 年生の秋に競技プログラミングを始めてからレッドコーダーになるまで、そして国際情報オリンピ
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
How to Deal with Difficult People on Software Projects
Software is easy. People are hard.
「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
英語力と技術力向上のための海外Tech系Youtuber10選 +n - Qiita
身につまされる英語力問題。手っ取り早く英語を習得するなら海外に行ってしまうが最善なはずですがこのコロナ禍、身近なところで英語に触れつつ技術も勉強したい？といえば、動画です。 10 Developers You Should Follow to Improve Your Skills (スキルを上げるための、フォローすべき開発者10選) という記事があったので10人をまとめた。プラスオマケ。それぞれ実際に動画を見てみての補足付き。 1. Ben Awad (ベン・アワド) ソフトウェア開発者。React、React Native、GraphQL、Typescript、Node.js、PostgreSQL、Python、その他あらゆるコーディングについて紹介。React.jsやGraphQLの開発者にお勧め。ビッグ／テック コーディングインタビューの準備を手ほどきしている。「アルゴリズム形式の
開発者が考える提案書テンプレート markdown版 - Qiita
概要 定型的な システム開発 では以下のような設計書が使われる。 システム要件定義 システム方式定義 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 しかしそれ以前に 開発者目線、開発者発信で顧客に提案する概要資料を作りたい ケースがある。あるいは就職活動時の自身のポートフォリオを採用担当に説明することも同様かもしれません。 オードリー・タンがコード書く前にまずreadme.txtを書く話、Yahoo!がプロダクト開発の最初にプレスリリースから作る話、自分が前職で商品企画する際にまず広告から考えていた話、どれも明確なゴールイメージをまず確定させて必要要件を定義していくという意味で全部共通の考え方 — 菅俊一 / Syunichi SUGE (@ssuge) February 2, 2021 なんて話も。 技術とマーケティングのちょうど中間、開発者と顧客との意思疎通の橋渡し
Lチカを超えて電子工作をちゃんと知るための「n講」第1回：ToF距離センサの仕組み | Device Plus - デバプラ
しっかりとした正しい知識を基礎から学び、長く電子工作を楽しむことができるようになることを目的とした今回の連載。分かりやすく解説してくれるのは、金沢大学電子情報通信学類教授の秋田純一先生です。記念すべき第1弾はセンサの仕組みを解説。 第1回となる今回は数あるセンサの中から、ToF距離センサについて解説をしていただきます。 目次 いろいろな距離の計測方法 ToFセンサと使い方 ToF距離センサの原理 カメラとToF距離センサ まとめ 1. いろいろな距離の計測方法 みなさん、こんにちは。金沢大学の秋田純一と申します。よろしくお願いいたします。 早速ですが、マイコンを使って何か作るとき、距離を測りたいことって、よくありますよね？ 例えば障害物をよけて進むロボットとか、手を近づけたらアルコール消毒液を出す、といった場合です。こういうときは、いわゆる「距離センサ」を使うことになります。 対象物までの
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
人間にうまく負けるためのゲームＡＩはいかに開発されているのか。将棋、囲碁、麻雀などの定番系ゲームを手掛ける開発会社に聞いてみた
どんどん強くなる将棋ＡＩ。 あの藤井聡太二冠ですら「ソフトと対戦することはありません」と発言し、人類ＶＳコンピューターという構図は過去のものとなった観があります。 ですが一方で、人間と戦い、そして負けることを目的とした将棋ＡＩもあります。 それはゲームソフトとしての将棋ＡＩです。 弱すぎてもダメだし、強すぎてもクリアできないから面白くない……そんなユーザーの要望に応え、家庭用ゲームソフトとしての将棋ＡＩを２０年以上作り続けている会社が、なんと岐阜にありました。私の実家から車で４０分くらいの場所に……。 『超速３七銀戦法』で升田幸三賞を受賞したプロ棋士の星野良生五段を正社員として登用した会社と言えば、ピンとくる方もいらっしゃるのではないでしょうか？ しかもその会社は……１２月１７日に発売となる『りゅうおうのおしごと！』のゲームにも将棋エンジンを提供してくれているというではありませんか！ これ
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
Linuxを生み出したリーナス・トーバルズが考える「優れたコード」とは何か？
プログラミングをする上で、コメントをきちんと残したり、わかりやすい変数名をつけたりして「読みやすいコード」を目指す作業は重要です。しかし、「読みやすいコード」と「優れたコード」の間には、時として構造上の大きな違いがあるのも事実。そんな「優れたコード」に対するLinuxの開発者リーナス・トーバルズ氏の考え方について、エンジニアのmkirchner氏が説明しています。 mkirchner/linked-list-good-taste: Linus Torvalds' linked list argument for good taste, explained https://github.com/mkirchner/linked-list-good-taste Linus Torvalds: The mind behind Linux | TED Talk https://www.ted.co
「いかにして問題をとくか」をいかにして読みとくか - Magnolia Tech
いかにして問題をとくか 作者:G. ポリア発売日: 1975/04/01メディア: 単行本 繰り返し読み返すべき技術書、今回はGポリア著「いかにして問題をとくか」を取り上げる。 この本は、本来は"数学を解こうとする教師と学生のため"に書かれた本だ。所謂コンピュータサイエンスの技術書ではない。 だけど以前、この「いかにして問題をとくか」の中心となる”問題をとくための4つのステップ”、「問題を理解する」「計画をたてる」「計画を実行する」「ふり返ってみる」は、まさにソフトウェア開発のステップそのものであり、特に「問題を理解する」に出てくる「条件はかき表されているか」という問いかけを出発点として、ソフトウェア開発で必ず問題化する「暗黙知」について考察するスライドを書いて、そこそこ評価していただいた。 blog.magnolia.tech 個人的にはこの本を最近宣伝されてるような所謂ビジネス書として
【2020年版】フロントエンドのおすすめMac無料ツール - Qiita
フロントエンドだけではないかもしれないけど、 エンジニアがおすすめするMac無料ツール2020下半期まとめです。 関係ないけど10人くらいサンタが家に来てくれないかな.... ■ Mac Apps 1. VSCode だいたいのエンジニアがみんな使ってるよね。って思うけど一応記載しときまっす。エディタなんて好みだと思うけどね。 こやつは拡張性高いし必須だと思ってます。 好きなテーマはDraculaです。 2. Draw.io Integration VSCode拡張。Drow.io単体でも使うけど Draw.ioをVSCode内で利用できる。エディタ内でグリグリ製図するの楽しいね。 3. Biscuit アプリ一元管理ツール。 BiscuitにslackとかNotionとかInoreaderを食べさせて便利につかわせていただいております。 Stationよりも使いやすいし動作が軽い。あとロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Among Us』開発者は大ヒットにより「燃え尽きた」―突如人気になったインディーゲーム開発者が明かす大きな期待を背負う苦労 | Game*Spark - 国内・海外ゲーム情報サイト
