JavaScript / TypeScriptの引数をひと工夫しよう｜Showcase Gig Product Team Blog
こんにちは、2020年10月に入社したばかりの坂口です。現在SET(Software Enginner in Test)として頑張っています💪 SETでは主にE2Eテストの作成/保守を担当しています。弊社のプロダクトはWebアプリケーションが多いため、WebのE2EテストとしてPlaywrightを採用し日々テストの拡充をしています。 日々テストコードを書いている中で少しでも可読性をあげようと引数を工夫してわかりやすくした例を紹介します。 環境・Node.js 15.8.0 ・TypeScript 4.2.3 この記事ではより恩恵が受けられるTypeScriptを使います。 オブジェクト引数引数は通常numberを受け取ったり、stringを受け取ったり、クラスやインターフェースといった型を引数に指定します。 async function setLocation(latitude: nu
マイクとカメラを妥協しないミニマルデスクをつくる｜Jun Tanaka
Noteの皆様、はじめまして。 今年はワークスタイルの変化に伴い、自宅の作業環境を改めて整備した方も多いのではないでしょうか。私が所属するツクルバでも、エンジニアが所属するチームは春から全面的にリモート体制へ移行しました。 その後、オンラインミーティング向けに自宅の作業環境のアップデートを重ね、その変遷を社内で共有したところ大変好評をいただいたので、Noteでも共有することにしました。少々長い記事ですが、お付き合いいただけると嬉しいです。 Macだけで良かった時代前職時代にリモートワークが許可されていたこともあり、以前から自宅の作業環境を既に整備していたので、リモート体制への移行はスムーズでした。下の写真は数年前の自宅デスクです。デスク上にiMacしかない、素晴らしい環境でした。 これなら、かのデスクすっきりマガジンの皆様もニッコリしてくれるでしょう。 しかし、今年になってこのすっきりデス
エンジニアとギタリストを両立するための最強のデスク環境｜wadap
多くの人が、ギタリストとしての自分とエンジニアとしての自分をどう両立しているか迷っているのではないでしょうか。僕もまた、そんな悩みを抱える者のうちの一人です。 特にリモートワーク中心の生活となると、自宅にいる時間が長くなってくるためどうしても環境を快適にしたくなるもの。 もともとこういった環境づくりは好きで、いままでいろいろと組み替えて来たのですが、最近またバージョンアップをしました。 いろいろな方々の記事を参考にしたのですが、特に参考にしたのがこちらの記事です。大変参考になりました。ありがとうございます。 コンセプト自分が長く過ごす上でどういったコンセプトで作るか？という点は重要です。僕の場合は以下の点を重視することにしました。 ・スタンディング環境にも変化でき、ケーブル類が整理されているデスク ・仕事、ギターともにすぐにとりかかれる環境 ・音楽機材が機能的に配置されている それぞれのコ
「エンジニアのチームを整える技術」66P無料公開します【技術書典7新刊】｜karamage@柿本 匡章
【技術書典7新刊】「エンジニアのチームを整える技術」についてどうも！ 「エンジニアのチームを整える技術」 著者のkaramageです。 2019/9/22(日) 技術書典7 サークル「からまげ＠うまうまだよもん」にて 以下の書籍を3冊頒布しました。 【既刊】累計1000冊販売「エンジニアの心を整える技術」 【新刊】「エンジニアのチームを整える技術」 【新刊】「たった 1 人で SaaS をグロースさせる データ分析秘伝の書」 サークル紹介ページ https://techbookfest.org/event/tbf07/circle/5728090902757376 このnoteでは、「エンジニアのチームを整える技術」の前半66ページを 無料公開します。 【整えるシリーズ第二弾】 「エンジニアのチームを整える技術」 本書には、チーム開発を成功に導くためのマインドセットについて書きました。 チ
多様性と均一性のちがいについて｜深津 貴之 (fladdict)
健全なnoteコミュニティを設計するうえで、チーム向けの多様性に関するメモ。多様性は色で考えるとわかりやすい。 昨今、多様性に関する議論が活発化してきている。不利な人々に優遇措置を与える、アファーマティヴアクションなども、どんどん増えてきてる。 でも、ちょっと怖いのが、「多様性」と「均一性」の違い。これが、あまり議論や区別されないまま、ドンドン進められているに思える。 多様性は色で考えてみようわかりやすいモデルとして、多様性を色で考えてみましょう。パレットや絵画をイメージしてください。 赤1色。これは全く多様性のない状態。意見や行動が完全に統一された世界です。これは一切の選択肢のない世界です。 様々な色を列挙した図。同じ職場に、白人と東洋人と黒人とヒスパニックの人々がいるようなイメージですね。一見多様性があるように見えますが… 実は、これをさらに離れて俯瞰をしてみると、こうなります。 ミク
実践TypeScript - 内容のご紹介 -｜Takepepe
ここ最近、TypeScript の盛り上がりが本当にすごいですね。私ごとながら、昨年末からずっと書き続けていた TypeScript の技術書が、ようやく本日校了しました。Twitter で告知をしたところ、想像以上に反響があり驚いています。あれだけ高価な本、予約するには情報が不十分です。「買ってみたが期待はずれだった」という方が出ないよう、内容についてご紹介します。 対象読者もし皆さまが、体型的にアプリケーションを構築する術を身に付けたいと考えているなら、別途、書籍や文献をお求めください。本書は、JavaScript には存在しない、TypeScript 特有の知識を体系的に学ぶための一冊です。想定している対象読者は、ある程度 JavaScript でアプリケーションを作った経験がある方で、型の話がメインです。 本書の目的様々な事情から、TypeScript の現場導
何故やりたいことがわからずに悩み続けてしまうのか？｜こばかな
こんにちは、THE GUILDのこばかなです。デザインとかコーチングをやっています。 最近ほぼ毎日コーチングをしているのですが、もっとも多いのはキャリアに関する相談で「やりたいことを明確にしたい」というテーマです。 いまは選択肢が多い時代なので、誰でも一度は「あ〜〜現状のままでいいのかな〜〜Aの方がいいかな〜〜それともBの方がいいかな〜〜」と人生について悩むことがあるでしょう。 ということで、いろんな方々の話を聞いた経験からモヤモヤと悩み続けてしまうときのよくあるパターンをまとめてみました（もちろん当てはまらない人もいるのでその前提で読み進めてください）。 やってみたいことはあるけれど、なんとなく無理だと感じる現状にモヤモヤしてるとき「本当はこうしたい」という本心に気付けないことが多いです。なぜならその本心に従うことは現実的にハードルが高いと感じていて、無意識に選択肢から除外してしまうため
レコメンドシステム入門 Javascriptで実装する｜es
レコメンド（推薦システム）に関して素晴らしい記事があったので訳してみました。訳に難があるが、そこはご勘弁ください。 プログラム実行してみると理解できると思います。入門者に打って付けの記事です。 以下、本文。 インターネットの世界はレコメンドで溢れていますね。 Amazonのように商品を購入するeコマース・サイト、Facebookのようなソーシャルネットワーク、YoutubeやNetflixのようなビデオ/映画サイトなど。これらのサイトに共通するのは、あなたに新しいものを推薦するために、映画、商品と友人などの過去のデータを使うことです。 この記事では、レコメンド機能がJavaScriptで、どのように動くか簡単に紹介します。推薦システムを実現するための、異なるアプローチも見ていきます。最終的にはアルゴリズムを切り替えただけで、結果を出力できるようにします。映画評論家の小さいデータセットと、M
チームの症状と処方の考察｜Megumi Kaneko
はじめに自己紹介を少しさせてください。 私はクライアントワークで約30名規模の開発チームに1年間ほどジョインしていました。役割は5〜10名のエンジニアで構成されるチームのプロダクトオーナーとしてだったり、UIデザイナーとPMのチームのスクラムマスターとしてだったり、色んな形でチームに接してきました。 その中で経験したことが、広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」を読んで色々整理されたので、チームが陥りがちな問題について稚拙ながら考察を書きたいと思います。 チームの健康状態とはチームの状態を表す指標として心理的安全性はよく聞きますよね。 広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」には心理的安全性について下記のように書かれていました。 「問題点の指摘」や「自分の弱
サービスに求められるものを、6段階に分類する｜深津 貴之 (fladdict)
「サービスの体験をよくする」というのが、漠然としてどうすればいいかわからないとき、まずユーザー体験を6段階に分類するのをオススメします。 この図をベースに、 ・あなたのプロダクトの現状 ・やろうとする施策やアップデートが、それぞれどのレイヤーに属するかを見て、基本は低レイヤー（機能より）のものから、充足させてゆきます。 下記は、家を例にしたのユーザー体験です。 Lv 0. 存在しない家がない。寒い。そして何も解決してない。 Lv 1. 機能がある屋根と壁と床がある。とりあえず雨風がしのげる。色々と我慢すれば、まぁ生きていける。 Lv 2. 安全と安心地震で壊れない。水漏れしない、火災報知器がついた、ドアに鍵がかかるようになった。最低限の信頼性が担保できる状態です。 Lv 3. 使いやすい、わかりやすいまっとうに使えるか。家のなかで迷わない。生活導線が機能するか。キッチンや冷暖房などがスムー
『ふりかえり』が開発チームを強くする｜あっきー
ハンズシェアでは２週間のスプリントを切りスクラムを組んで開発をし、スプリントの終わりにふりかえりをしています。『アジャイルレトロスペクティブ』を読んでふりかえり手法を改善した取り組みを紹介します。 これまでの『ふりかえり』これまでスプリントレトロスペクティブ（ふりかえり）をKPTのフレームワークを使い改善を行ってました。 KPTとは、Keep/Problem/Tryの頭文字を取ったもの １．Keep（良かったこと、続けたいこと）を出す ２．Problem（問題、開発の妨げになったこと）を出す ３．Try（Keepを更に良くする案、Problemを改善する案）を出す ４．Tryに投票し改善していくことを決めるKPTでのふりかえりをしている中で下記のような問題を感じていました。 ・KPTが形骸化 ・スプリントでやったことをそんなに覚えてない ・チームの問題発見・改善に対してクリティカルなものが
とりあえず最短距離で、幸せと充足を求めるためのアレコレ｜深津 貴之 (fladdict)
幸せ系の本を読んで自分で試し、再現性の高いと思った手段まとめ。 「まっとうな幸せ」に関する話はnoteにいっぱいある。それで幸せになれない人のための、よりエクストリームな幸せのガチコスパ獲得方法について。 最低限の「健康」と「収入」と「人間関係」は前提だけど、人は割とノウハウでローコスト＆短時間に幸せになれるのではないかと思う。 小さい幸せをたくさん持つ一つの幸せに人生をつぎ込まない。幸福は逓減（鈍化）するので、一点集中で追求するほど効率が悪くなる。1000万円のディナー1回より、1万円のディナー1000回のほうが幸福の総和は高い。また単独の幸福は、失われた時のダメージがでかい。幸せの発生源を最低でも3つ持つとよい。 小さい幸せをたくさん持つと、最もコスパが良い。朝ごはんが美味しいとか、日向ぼっことか大事。たまにアクセントにデカイ幸せを入れる。 複数の幸せをグルグル回すケーキを大量に食べる
課金 UI まとめてみた｜あき - 良いもの作って正しく届ける
売上を伸ばしたい。 課金率を伸ばしたい。 でも、難しい！ コンバージョンするサブスク UI を勉強したかったので、いくつかのアプリをスクショ。あたまの整理にまとめたのでアップ。 Web の LPO はかなりノウハウ系記事がありますが、アプリのサブスク UI は、まだまだ少ない気がします。誰かの参考になれば嬉しいです。 まとめ内のコメントは個人的感想です。まだまだ勉強中なので、お気軽にご意見いただけるとうれしいです。 ※ スクショは少し前に撮影したものなので、一部古くなってるかもしれません。 UI パターン 1. ミニマム型 2. プラン比較型 3. 横スクロール型 4. リスト型 5. ロング LP 型 規約表示パターン 1. 固定表示型 2. 隠しスクロール型 3. フッター型 4. 遷移型 サービスパターン 1. 探索財 2. 経験財 3. 信頼材 UI パターン1. ミニマム型最低限
はてブロかnoteか、技術者はどこで技術ブログを書くと幸せになれる？｜吉田勇太｜ysdyt
（※有料noteになっていますが、全文掲載しています。もし気に入ったらサポートお願いします！） 技術者とブログ最近noteを使い始める技術者の人たちが増えてきている気がします。 なので今回は、技術ブログを書くときにnoteは使いやすいのか、はてブロとどう違うのかという話を書こうと思います。（ここでいう「技術者」は特に「記事内にコードを貼り付ける系のブログ書く人」程度の感じを想定しています） 自分もnoteで「WEEKLY人工無脳」という人工知能・データサイエンスに関する最新の話題を要約・解説するブログをnoteとはてブロの両方で書いてきました。 コードの貼り付けはしてないので自分の中では「技術系ブログ」ではないのですが、世間一般には「技術系ブログ」にカテゴライズされているようです。 技術ブログといえば、他にも「Medium」という選択肢もありますが、Mediumは昔、日本語URLが死ぬほど
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。｜じゅ ごん｜note
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 [Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」 と思っていたりします。こんな話、
プロダクトの歴史を共有することの大切さ｜クックパッドマート｜note
はじめましてクックパッドマートの開発チームでデザイナー兼エンジニアをしている長野と申します。 私は先日ブログや登壇で、クックパッドマートの立ち上げから現在に至るまでのプロセスをお話しする機会がありました。このnoteでは、その時に感じた「プロダクトの歴史を共有することの大切さ」について、書いてみたいと思います。 クックパッドマートの歴史にご興味がある方は、下記のリンク先もぜひどうぞ。 チームの議論が前向きになるプロダクトの歴史が共有できると、「なぜプロダクトが今その形になっているのか」その理由が理解されるようになります。そうすると、議論の方向性が自然と未来を向いた建設的なものになるという実感があり、それが歴史を共有することの直接的な効果ではないかなと感じています。 例えば、クックパッドマートのサービスの今の形だけをみた場合、 なぜクックパッドマートは、 ・専門店の商品しか扱わないのか？ そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
