What's PWA ? Progressive Web Apps （プログレッシブ　ウェブ　アップス）の略 Googleが推進している、モバイルユーザーの体験（UX）向上を目的とするプロジェクト・技術のこと PWAは、わざわざApple StoreやGoogle Play Storeからインストールする必要はありません 不安定なネットワークでも迅速に起動し、関連性の高いプッシュ通知を送信することができます。 ホーム画面にアイコンを表示することができ、トップレベルの全画面表示で読み込むことができます。 ▼このように、Webサイトを直接ホームに追加することでアプリケーション化されます 導入事例 大手WEBサイトからで導入がはじまりつつあります コンバージョンアップにも効果的です Trivago https://www.trivago.com Twitter Lite https://mobi

開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため1 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず

2016年8月時点の結果報告を追記します！ ということで、概ね１ヶ月継続が65%から70%という状況をキープしています。 フェーズ的に中長期施策をアプリで打てなかったので、半年継続はもう少し改善できると思いますが、３月継続でも半数を維持していますので概ね間違った選択はしていないことが証明されたかと思います。 エンジニアがディレクションをして１ヶ月継続率を半年で15%改善した方法 最近は技術職でもサービス改善の前線を担う一員として、「KPIの数値目標を個人目標に設定された！」というのは珍しい話ではないと思います。 私も、前々職では所属部署の目標としてそういった数値目標はありました。 個人目標としてはエンジニアとしての目標の設定でしたが、前職では旧来であれば企画職がもつ数値の目標を設定していただいたり、以前務めた会社では少数チームでエンジニアとはいえ、運営的なKPIを個人目標に設定いただいたり

dev.to を見ていたら、 #impostorsyndrome というタグがあり、 #shecoded でもけっこうみんな Impostor Syndrome に苦しんでいたという記述がありました。 調べてみたら、 Impostor Syndrome （詐欺師症候群） に陥っている方は多いんじゃないかと思い、というか自分がまさに当てはまった気がしたので、エンジニアの視点でまとめてみます。 Impostor Syndrome とは wikipedia によると インポスター症候群またはインポスター・シンドローム(英: Impostor syndrome) は、自分の達成を内面的に肯定できず、自分は詐欺師であると感じる傾向であり、一般的には、社会的に成功した人たちの中に多く見られる。 能力の高い人々は、自分が偽物であると人から思われたくないがために、熱心に働く傾向がある。その勤勉さの結果、人

アダルト業界でデザイナーとして働いていた頃、 あるデザイナーの「ゆるやかな死」を見たことがある。 ここでいう「ゆるやかな死」というのは、 「アウトプットの決定的な低下」のこと。 ▼ 音声で聞きたい方はこちらからお聴きくださいｂ ▼ エースデザイナーの「異変」その人（以後、Nさんとします）は僕が新卒入社する前から、DVDジャケットのデザインを1ヶ月で10点前後作り続けている現役バリバリのグラフィックデザイナーだった。 月で10点は、ジャケット以外の業務も含めれば余裕で週3くらいは残業が必要な量。それをNさんは月に1回くらいの残業で平気にこなす。 言うなればエース、シニアとも言えるデザイナーさんだった。 そんなNさんがある時から変化が生じ始める。 アウトプットのテンプレ化AVは「シリーズもの」が多い。 かの有名な「マジックミラー号」も、様々なシリーズ、企画内容が出ているが、それらをまとめて「マ

昨日 2月末に株式会社groovesを退職します を発表したエンジニアのマネージャーを務めている（2018年1月時点）赤川です。 本記事の前半では、なぜ彼が望む「フレックスでの深夜勤務」を用意できなかったかを紹介し、後半では彼と共にプロダクト開発に携わってきた立場から、彼の推薦文を書きます。 なぜこの記事を書くのか？ フレックス制度の導入を検討している会社の参考にしてほしい エンジニアの成長・キャリアアップを応援する Forkwell を運営している会社が、自社のエンジニアのキャリアアップや転職を応援しないのは嘘になるので、感謝をこめて送り出したい 今回の経緯 まず、今回の件について、彼とどのように会話を進めてきたかを紹介します。 2017年8月　1on1 MTG で、自身の生産性をあげるためにフレックスを導入したいと伝えられる。フレックスについて調査開始。 10月　エンジニアチームに、深

最近、自分のキャリアを考えていて、35歳定年説について考えてしまった。プログラマーに限らず、35歳というのは結構過渡期ではないかと感じている。最近もまつもとゆきひろさんのこんな記事があった。 http://hrnabi.com/2017/12/06/15766/hrnabi.com プログラマー35歳限界説というのは、おそらくマネージャーかプログラマーかのキャリアの分岐点であり、未だにキャリアを上げていくためにはマネジメントしかない環境でのことだと思う。ただ、私がいた環境も含め、これは徐々に変わってきていて、エンジニア自体が足りないという時代背景もあり、ある程度自己研鑽さえやっておけば、35歳以降もプログラマーとしてやっていくことは十分可能になってきたのではないかと思う。できない環境の方は、是非転職してみたらいかがだろうか。 そこでプログラマーだけでなく、ちょっと話を拡大して、もう少し仕事

こまたつです。 この記事は 退職者アドベントカレンダー の20日目です。 adventar.org 退職、流行ってますね！！*1 お前誰という人が多いかもしれないので、簡単に経歴を書いておきます。 新卒で小さいSI -> DMM.com Lab -> Cookpad と今回で退職は3回目です。 2012年くらいからAndroidエンジニアで、その前はstrutsとかCOBOLとかPL/SQLとかエクセル・ホーガン氏やってました。 クッ社ではJenkinsおじさんをやったり、やめる前はサービス開発をもりもり頑張っていました。 なんでやめたの クッ社はフレックス三食シャワー昼寝付きリモート可で強いエンジニアと研鑽できる、過去最高にいい環境だったのですが、次の理由があってやめることにしました。 東京のスラムと呼ばれる恵比寿での生活で消耗した*2 入社時に比べてだいぶ成長したので、独力でどのくらい

いわゆる人工知能技術が巷をにぎわす昨今、人工知能を研究する部署/団体を設立するのがトレンドになっています。もちろん、部署の設立にはそれをマネジメントする人間が必要です。「その時」は突然やってきます。 「わが社でも人工知能技術を研究しビジネスに役立てるべく、新しい部門を設立することになった」 「はい」 「ひいては、君にその部門のマネジメントを任せたい」 「！？」 「将来的には100人規模にし3億円規模のビジネスにしたいと思っている(※)。まずは中期計画を作成してくれ」 「そ、それは・・・」 「部門設立のプレスリリースは来月発行される。よろしく頼むよ(肩ﾎﾟﾝｯ」 (※: 好きな数字を入れてください) (from 疾風伝説 特攻の拓) 本文書は、実際こうした事態が起こった時に役立つチェックリストとして機能するようにしてあります。具体的には、以下の構成をとっています。 設立編: 何を「目指す」の

本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

はじめに クラウドワークスの初期バージョンを作ってから早6年。後任のエンジニアたちには様々なdisりを受けてきました。 システムアーキテクチャや設計（命名は除く）に関するdisりについては、何よりもビジネスを軌道に乗せることが優先されるタイミングでどこまで「ちゃんと」やるべきか、という議論の余地が常にあります（自分のスキル不足については、いったん棚に上げます）。 一方、「命名」については、サービス立ち上げ期であっても「ちゃんと」やるべきと断言できます。 なぜならば、 システム外（例えば、非エンジニアとのコミュニケーション）にも関係してくる、ある意味ではシステムの最も基礎的な部分と言えるため、ここでしくじると影響範囲がでかい ネーミングをがんばったからといって、それ自体にかかる時間はたかが知れているし、その後の開発速度に悪影響を与えることもほとんどない すなわち、命名を「ちゃんと」考えるとい

Web技術の標準化団体であるW3Cは、HTML 5のマイナーバージョンアップである「HTML 5.2」の策定を完了し、勧告としました。 HTML 5.2ではいくつかの機能追加、削除、バグフィクスなどが行われています。 機能追加の例では、ダイアログボックスを表示する＜dialog＞要素が追加されました。下記は＜dialog＞要素を用いたサンプルです。 ... <body> <div> <!-- body content --> </div> <dialog> <h1>Add to Wallet</h1> <label for="num">How many gold coins do you want to add to your wallet?</label> <div><input name=amt id="num" type=number min=0 step=0.01 value=10

この情報は古いです。リライトしました。 http://hikouki.hateblo.jp/entry/2019/05/31/164944 この記事は CrowdWorks Advent Calendar 2017 の14日目です。 エンジニアリーダーの @hikouki です。 0からDDDでアプリケーションを立ち上げ中ですが、バリデーションの壁にぶち当たったので、 「バリデーション」はどう扱えばいいのか考えてみました。 ここでは、ユーザー(外部システム)入力値に対する検証に限定します。 どこでユーザー入力値を検証するべきか ユーザー入力値のバリデーションは全て、Presentersion層で行うべきだと考えました。 理由は、「Application層に来た時点でユーザー入力値ではない」からです。 なので、Application層の引数が不正な場合は、例外(内部エラー)として扱うようにし

SREチームの那須です。好きな鉱物はダイヤモンドです。宝石の国は今期イチオシのアニメです。ダイヤモンドかわいい。 最近のことですがCrowdWorksにもSREチームというものが誕生しました。CrowdWorks の最近の取り組みについての記事でも取り上げています。 engineer.crowdworks.jp SRE とは Site Reliability Engineer の略でGoogleが提唱している概念です。主にサイトの信頼性向上や運用の自動化などインフラの仕事を、ソフトウェアエンジニア的な問題解決手法で行っていく人たちのことを指すようです。 そんなSREのチームが CrowdWorks にも誕生しました。自分はインフラの知見があまりないのですが、チャレンジとしてSREチームに加わり現在 CrowdWorks のインフラ周りと格闘しています。今回はそんなSREチームの背景や最近の

この記事は CrowdWorks Advent Calendar 2017 の11日目の記事です。 はじめに はじめまして。 クラウドワークスのアプリ「Crowdworks for Worker」のプロダクトオーナーをしている @kanako16 です。 突然ですが、最近施策を考えたりするときにこんな悩みにぶつかった時がありました。 「Webのこの機能をアプリに展開したいけどWeb側使いにくい。そのままアプリに展開していいの？」 クラウドワークスでは、先行リリースしているWebの機能をアプリでサポートできていない部分があり、Webの機能をアプリに展開していく場面があります。 昨日の @tkoshida さんが公開した「クラウドワークスのiOSアプリ会員登録を改善した話」も、ブラウザに遷移させていた会員登録機能をネイティブ化した事例の一つです。さらに会員登録の前にも、今までアプリからはブラウ

この記事はCrowdWorks Advent Calendar 2017の10日目の記事です。 はじめに クラウドワークスでiOSアプリエンジニアをやっています@tkoshidaです。 クラウドワークスではお仕事を受注するクラウドワーカー向けのiOSアプリCrowdWorks for WorkerをApp Storeで公開しています。 社内では最近そのiOS/AndroidアプリがWeb側のサービスと比較して継続率が高かったりすることなどから、アプリに注力するようになってきています。 今回はこれまで課題が多かったアプリ会員登録まわりの、iOSアプリにおける改善の取り組みについてご紹介できればと思います。 これまでのアプリでの会員登録の流れとその課題 これまでのアプリでの会員登録は次のような流れでした。 このように、アプリインストール後に会員登録しようとメールアドレスを登録すると確認メールを

この記事は CrowdWorks Advent Calendar 2017 の9日目の記事です。 表題の件ですが、僕もです( ^ω^ )ﾆｺﾘ 今いるチームは開発を新規でどんどんやるチームではなくどちらかというと今あるサービスを安全に当たり前に使い続けるために変更を加えつつついでに整理する事が多いです。 突然ですが、こんな経験はありませんか？ あなたは既存のメソッドに機能を追加しようとしています。しかし、そのコードたちはもともと煩雑に作られている上に建て増し建て増しをされたことがわかる程度の雑さで重ねられ、もはやだれも相手できないモンスターに。。。 ひのきのぼうを渡したら討伐してきてくれる勇者は現実世界にはいないので、なんとか自分たちでやるしかないですね。 新規でつくるならこうするのに。。。 ここに追加機能を足したいからまずはここをこうしてこうしてこうして...わ～( ;ﾟ皿ﾟ)ﾉｼΣﾊﾞ

The zero configuration build tool for the web. JavaScript. CSS. HTML. TypeScript. React. images. SASS. SVG. Vue. libraries. Less. CoffeeScript. Node. Stylus. Pug. Electron. Elm. WebGL. extensions. GraphQL. MDX. XML. Parcel combines a great out-of-the-box development experience with a scalable architecture that can take your project from just getting started to massive production application.

はじめに この記事は CrowdWorks Advent Calendar 2017 の8日目の記事です。 Terraform職人の @minamijoyo です。Infrastructure as Codeしてますか？ インフラのコード管理に Terraform を使い始めて2年ちょっと、本番環境で運用していると日々色んな学びがあるので、Terraformやってみた系の入門記事では語られない、現場の運用ノウハウ的なものを共有してみようかと思います。 Terraformを使い始めた or 使っている人が、こんなときどうするの？っていうときに参考になれば幸いです。 書き始めたら超長文になりました。概要は以下のとおりです。 公式ドキュメントを読もう tfファイルを書く技術 インデントを揃える 組み込み関数に親しむ lifecycleブロックを使う リソースの差分を無視する リソース再生成のとき