出欠について、都教委は「校長が判断」とした上で、「子どもたちの不利益にならないような方向で対応してほしい」と呼びかけている
出欠について、都教委は「校長が判断」とした上で、「子どもたちの不利益にならないような方向で対応してほしい」と呼びかけている
Effective Kotlin という電子書籍に、Kotlin コードの可読性に関していろいろためになることが書いてあるのでメモメモ。 読みやすさのためのデザイン (Design for readability) 昔ながらの実装 vs Kotlin 的な実装 下記の実装 A と B はどちらが読みやすいでしょうか？ // 実装 A if (person != null && person.isAdult) { view.showPerson(person) } else { view.showError() } // 実装 B person?.takeIf { it.isAdult } ?.let(view::showPerson) ?: view.showError() どちらが読みやすいかは読む人のスキルによりますが、A の方が変更しやすく、デバッグしやすいです。 条件分岐を増やそう
富士通グループが、クラウド型名刺管理サービス「Sansan」を導入した。約8万人のグループ社員が利用し、データ化した名刺を保管、活用する。保存したデータをCRM（顧客関係管理）ツールなどと連携させる機能「Sansan Data Hub」も採用。提供会社のSanSanが4月22日に発表した。 社員は今後、オンラインでの名刺交換などでSanSanを活用する。集めた名刺のデータはCRMツール「Salesforce」と連携し、マーケティングや営業活動に役立てるという。 ニューノーマルに対応した働き方を実現する取り組み「Work Life Shift」の一環。富士通グループは2020年7月に国内の社員を原則リモートワークでの勤務にするなど、働き方改革を進めている。 【訂正：2021年4月22日午後4時30分 タイトルの誤記を修正しました】 関連記事 経産省も「オンライン名刺交換」に対応 約4000人
こんにちは！関西支店勤務の大西です。 私の役割は、Bill One事業のプロダクト開発責任者という立場で、プロダクトマネジメントと開発マネージャーの役割を担っています。今回のブログでは、開発マネージャーの立場から、Bill One エンジニア組織の目指す文化を紹介させてもらいます。 Bill Oneとは Bill Oneとは「あらゆる請求書をオンラインで受け取る」をコンセプトに去年の5月にローンチしたサービスです。最近では、テレビCMを開始しており、2022年5月末までに契約件数1,000件以上に向けて爆速成長モードです。 Bill One 「解せない」篇（60秒） 目指す文化 早速本題になりますが、目指すべき文化は 事業成果を最優先に各自が主体的に行動し、成長し、一体感を強く持つ文化 です。 例えるなら、家族のような文化ではなく、プロスポーツチームのような文化です。 プロスポーツには、以
Developer Experience Day 2021での発表資料です https://dxd2021.cto-a.org/developer-experience-day-2021
こんにちは。mhidakaです。技術書典やDroidKaigiのオーガナイザーという側面以外にもメルペイ所属のAndroidエンジニアという立場も持っています（みなさんあまり知らないと思いますので書いておきます）。 今日はメルカリ・メルペイでのモバイルアプリ大規模開発での、とあるアプローチをメモしておきます。内容は社内レビューを受けてマネージャの承認が取れたものなので安心して読んでください（自分のブログで書いてるのは真面目に書くと大変そうに感じる話題だったのと、なるべく楽しんでもらえるようカジュアルな口調で書きたかったからです） メルカリ・メルペイでモバイルエンジニアの開発対象というと主にアプリケーションです。大規模開発の重要な要素はアプリケーションだけではありませんが（考慮すべき要素はたくさんあるんですよ）今日はアプリのはなしです。本記事では一般化できるよう努めていますが大規模開発では組
mizdra.icon が社内向けに発表した資料なのですが、折角なので一般向けに書き直して公開します。
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
mime-typeに関する「データベース」であるfreedesktop.org.xmlに著作物性があるかどうか、という話。 例えばそのデータベースが下記のようなものだったら、これは単なる網羅的な事実の列挙であって、体型的な構成に創作性がないので「データベースの著作物」としての保護の対象にはならない。
新型コロナウイルス感染症に国民が不安を抱える中、「復興五輪」の象徴として福島県からスタートした東京五輪聖火リレー。初日の２５日に沿道で取材した記者が目にしたのはランナーより目立つスポンサー車両による「お祭り騒ぎ」だった。（原田遼）
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
こんにちはー。突然ですが、聞いてくださいよー。 Babelのバージョンアップしたら「Chatworkのルーム切り替えが重くなった」と社内で言われてしまいました。 みんなの仕事の効率を悪くするわけにもいかないので、戻すしかありません。Babelの更新って、本当に怖いですよねー。 そんなわけで、こんにちは。フロントエンド開発部のひむら(id:eiel)です。 さて、この話自体は少し前のことなのですが、その際に原因を特定する余裕がなく、Babelの更新は後回しになっていました。 ルーム切り替え自体が歴史的経緯もあって、「とーっても」*1難易度が高くなっていて、最悪これを改善すれば更新できるだろうと期待もしてたりもしました。 ところが、うっかり再発させてしまったので、ここで気合をいれて改善することにしました。 今日はその話を記録しておきます。 要約 経緯 原因の特定 試しにIE11をターゲットから
前提 3rd party版Dependabot GitHub版Dependabot どうしてGo.1.16以降はGitHub版Dependabotを使った方がいいのか？ 3rd party版 vs GitHub版 前提 一言でDependabotと言っても実は2種類あります 3rd party版Dependabot dependabot.com *1 設定ファイルは .dependabot/config.yml https://dependabot.com/docs/config-file/ 最初にできたやつ PRを作る時のユーザ名がdependabot-preview *2 GitHub版Dependabot docs.github.com 設定ファイルは .github/dependabot.yml https://docs.github.com/en/github/administe
はじめに BtoB開発部の増田です。 BtoB開発部は、主にFulfillment by ZOZO（以下、FBZ）の開発を担当しているエンジニアチームです。FBZの初回ローンチから間もなく3年経過しますが、サービスの拡大、拡張とともに見直すべき課題も増えてきました。日々の運用負荷の増大や、それに伴う開発効率の低下の話しを耳にする機会も増えています。そこで、今期の開発計画では、運用改善のための開発も優先度を上げて取り組むこととしていました。 一方で、新型コロナウィルスの影響もありチーム全体がリモートワークに移行して1年が経過しました。リモートワークが浸透する過程にはさまざまなコミュニケーション課題があり、上記の運用改善の施策を進める上でもコミュニケーションの円滑化が急務でした。 そのようなコミュニケーション課題の対策のひとつとして1on1に力を入れているチームも多いでしょう。この記事では、1
Kyashの@konifarです。最近雑なアウトプットが減っているなと感じているので、自分が所属するチームでやった『チームラーニング』という催しについて書きます。 チームラーニングとは マッキンゼーでプロジェクト開始時に行っているチームビルディングイベントらしいです。 働く時間帯や環境、自分の不得手などを共有することで、チームで働きやすい状態を作ろうというものですね。 バズってた「チームラーニング」をやってみたら、チームの生産性上がりそう という記事がSlackチャネルに投げ込まれたのを見て、これはよさそうだと思い実施してみることにしたのでした。 あとで同僚の@ussyに教えてもらったのですが、マッキンゼーでのやり方や効果はMcKinsey Careers: Inside the team learning – one tool to create balance で紹介されています。もし
プロダクトオーナー祭り2021 Spring - PO祭り2021Springにて、Spotify Modelをベースにしたクロスファンクショナル組織のあり方について話ました。 WealthParkでは、PdMを募集しています！ https://www.want…
※以下の記事は研修の内容を伝えることを意図したものではなく個人的な感想と学んだことを記載したものです。 Agile Testing for the Whole Team 研修 3/1~3/3の3日間で、アギレルゴコンサルティング主催のオンライン研修「Agile Testing for the Whole Team」に参加してきた。 www.jp.agilergo.com 講師は Janet Gregory（@janetgregoryca） さん。『実践アジャイルテスト』の著者の一人で、最近では『Agile Testing Condensed』という書籍も執筆している（こちらについても既にブロッコリーさん（id:nihonbuson） による邦訳がある）。 実践アジャイルテスト: テスターとアジャイルチームのための実践ガイド 作者:リサ クリスピン,ジャネット グレゴリー翔泳社Amazon
はじめに クラスメソッド株式会社で取締役及びAWS事業本部の本部長を努めております、佐々木と申します。 私は2014年1月にソリューションアーキテクトとして入社後、2015年7月よりAWSエンジニア部門の部長になりました。また事業拡大に伴って営業部門などを集約することとなり、2018年7月よりAWS事業本部の本部長となりました。この6年間、AWS事業部門のトップとして業務に従事しておりましたが、この度2021年6月をもって本部長を引退することにしました。 部長や本部長などの事業責任者は引退が難しいポジションのように思えるかもしれませんが、きちんと順序だてて計画すればスムーズに引退することが出来ます。この記事では、役職をどのようにして引退したら良いのかをご紹介します。 なぜ役職を引退するのか 最も大きな理由は「キャリアの固定化を防ぐこと」です。 私は本部長という役職で、事業本部の中に部があり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
graphql-design-tutorial/lang/TUTORIAL_JAPANESE.md at master · Shopify/graphql-design-tutorial
