All slide content and descriptions are owned by their creators.

こんなお悩みありませんか？次の案件を探すのが大変…短期間で案件が終了してしまうため、 経済的に不安定で落ち着かない 正社員と働き方が変わらない…フリーランスになっても結局、 週５・常駐時間固定の仕事をしている 自身の技術力に不安…レガシーな技術や同じ環境で開発していて、 モダンな言語を使った開発に携われない Findy Freelanceが支持される 3つの理由ユーザーサクセスの手厚いサポート面談後に最短での案件の紹介はもちろん、稼働後も請求書支払いのサポート、単価や働き方の条件交渉も可能。 ※最短3営業日以内で案件をご紹介 週２〜３日やフルリモートなど、 自分に合った働き方を選べるリモート案件が約70％、週2〜3日の案件が60％と、あなたの実現したいライフスタイルに合わせて、案件を紹介させていただきます。 スタートアップ企業を中心に モダンな環境で開発できるGo, Python, Rea

2017年10月20日に開催された第1回X-Tech JAWSでLoveTech代表として語ったのはマッチングサービス「Pairs（ペアーズ）」を手がけるエウレカの臼井友亮さん。「オンラインデーティング」の価値を上げるべく、AWSや機械学習をフル活用する現場の様子を生々しく語った。 600万人会員なのに、使っていることが共有されないPairs 「人の出会いを支えるPairsとAWSの切っても切れない関係」というタイトルで、いわゆる「LoveTech」でのAWS活用について語ったのは、エウレカの臼井さん。システム計画研究所、ハンズラボを経て、昨年エウレカに移ってきた。現在はSREチーム／サーバーサイドエンジニアとして、Go言語でアプリケーションを書いたり、開発チームをまとめたり、CTOとPairsの事業戦略を踏まえた中長期な技術戦略を共に考えているという。 さて、エウレカが手がけるPairs

自分がアウトプットして得たもの、伝えたいことをまとめました エモ！

JavaScript Advent Calendar 2017 - Qiitaの第一日目です。JavaScriptにおいてメタプログラミングを用いて、エンジニアリングにおける邪悪と闘うという趣旨の記事です。 秋のJavaScript祭 in mixi 2017 - Javascript祭りでこれからのメタプログラミングJavaScriptの正義を語ろうという発表をしてきました。この記事はそれをベースにしています。 技術書典3で頒布した簡単JavaScript AST入門という同人誌ですが、どうも電子版を求める声が多いので、簡単JavaScript AST入門 - 東京ラビットハウス - BOOTH で電子版を販売しています。 結論から メタプログラミングを活用すればこの三つを達成できます。 コーディングタイムコンパイルという新しい概念・技術 暖かみ溢れる手作業を根絶 生産性を向上して、相対

idやclassを使ってテストを書くのは、もはやアンチパターンである 上記の記事を書いたところ、様々な反応があり非常に勉強になりました。 中でも気になったのが、class名に規約を設け、test-というプレフィックスを付けるものです。 個人的には、カスタムデータ属性の方が分離する際の見通しが良く、またCSSinJSにも適用できるのでこちらを推しますが、チーム内で共通の理解がある場合は、クラス名で制約を付けるのは良い解決作だと思います😆 さらに言えば、この問題の本質は、いかにチーム内で同意が得られるかに尽きます(data-testを書いたところで共通認識がなければ意味がないですから) さて、class名のよるtest-プレフィックスについて、ちょっと見たところプロダクション時に取り除くプラグインはないようでした。 なのでちょっと作ってみました。 akameco/babel-plugin-r

いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと

コーディングタイムコンパイル 暖かき溢れる手作業による重複を根絶する 生産性を向上して、相対賃金を上げる

ツイッターが英語で280文字書けるようになりました🎉 つまり、ツイッター上でコードを書くのが現実的になったということですね。 せっかくなので、ツイートをライブラリとして使ってみましょう。適当に呟いて、import hello from 'twitter:あなたのツイート'と書いたら、Babelをつかってツイートをコンパイルして実行です。 How to Use babel-plugin-twitterをインストールして、create-babelrcで.babelrcを生成します。 $ yarn add --dev babel-{cli,preset-env,plugin-twitter} $ npx create-babelrc -o Created .babelrc { presets: [ 'env' ], plugins: [ 'twitter' ] }

リーダーと呼びましたが、いわばアンテナアプリ側です。複数のSSまとめサイトの SS リンクリストを表示します。 このアプリの一つ目の特徴は検索です。作品タグ + キャラ名で絞り込み、検索クエリをタブ化して保存できます。 もう一つの特徴は複数のサイトをあつかっていながらSSの重複がないことです。タイトルをある程度正規化して集約しています。 データは Rails で実装した API からとってきています。記事データは SS アンテナサイトの RSS を収集しています。SSをRSSで非SSRです。 実はこのアプリのコアはサーバーサイドで、収集やタグ整理、管理の自動化に力を入れています。 React Native で作っていた個人開発アプリを PWA に移行しました。(1から) 作っているものが Native である必要がないこと、アプリストア管理やリリース準備などの手間を感じていたこと、デバッグ

グローバルからコンポーネントベースのid管理へ サービスを海外展開したい場合、国際化対応を行う必要性があります。これをi18n対応と呼びます。Reactでフロントエンドを構築する場合、i18nのための多くのライブラリがありますが、ダウンロード数的にyahoo製のreact-intl が最も使われているライブラリです。react-intlを実際に使っている例としては、スター15000を超えるReactボイラープレートであるreact-boilerplate やSNSの マストドンがあります。 react-boilerplate/react-boilerplate: A highly scalable, offline-first foundation with the best developer experience and a focus on performance and best

ReactNativeプロジェクトで、型がないことによるつらいシーンが多くなり(特に変数の解釈に起因するバグ)、Facebook製の静的型解析ツールであるFlowを数ヶ月前に導入しました。導入時の学びと、しばらく運用して感じていることについて個人的な感想を書きました。 Flow選定理由 Javascriptで静的な型付けをするといえばTypeScript(正確にはJavascriptのスーパーセット)がありますが、プロジェクト途中からの導入しやすさの観点からFlowにしました。Flowはお作法(行頭に @flow つける等)さえ押さえれば誰でも使えることから導入障壁はだいぶ低いといえます。導入のメリットについては以下のスライドがとてもわかりやすいです。 speakerdeck.com flow status でプロジェクトに対して静的型解析を走らせることもできますが、 コーディング時にワー

なぜreducerのテストが重要か？ flow環境で型によって返るStateが担保されていたとしても、依然としてreducerのテストは重要です。 簡単な例をあげると、INCREMENTでcountが+1されるロジックがあるとき、number型であると保証されていたとしても、+1されているのか-1されているのか、はたまた+100000されているのかについては保証されていないからです。 そのロジックを担保するのがテストの役割です。 reducerのテストの書き方 flow環境とそれ以外でテストの書き方が違います。 トラディショナルなテストだと{type: ACTION}の形式でテストを書くことが多いと思いますが、flow環境だとActionが型で担保されているためアクションクリエイターをそのまま実行して書きます。 トラディショナルな書き方でもいいですが、この方が補完も効くのでオススメします。

はじめに JavaScriptで文字列の有無を調べるにはindexOfではなくtestを使う | iwb.jp という、謎タイトルの記事をみました。 なんだか、indexOfより、testの方が、可読性が高いらしい... いやいやそれは無いわー うーん、なんかJS界隈では有名なブログっぽい気がする。何回か見たことある。 しかし、これは、ちょっと同意できないな。 indexOfは、たいていどんな言語でもindexOfとして作られているのだから、可読性は低くない。というか、自分にとっては、読みやすい。 むしろ正規表現パターンを記載するほうが、めんどくさいし、読みにくいわ.... 極力、正規表現は自分のプログラムに入れ込みたくない。Perlしかない時代じゃあるまいし....正規表現を使いたいときは明示的に正規表現を使います。って場面だけで使う。これ鉄則ですわ。 これって、可読性低くないかなあ。

この資料のアレ。 mizchi.hatenablog.com Reducer は単なる (State, Action) => State の関数で、redux.combineReducers は複数の reducer を名前空間でマップした新しい reducer にするもの。 Rx分かる人、Redux分かる人向けに、 redux.combineReducers を実装して、Rx.Observable.scan で reducer として実際に動くコードを書いた。 const Rx = require('rx') const combineReducers = reducerMap => { const initialState = Object.entries( reducerMap ).reduce((acc, [key, reducer]) => { return Object.ass

まだアクションクリエイターを自分で書いているの？ reduxとflowtypeを使ってフロントエンドアプリケーションを構築していると、ボイラープレートが多く、面倒だと感じることがありませんか？ しかし、もはや、このAST時代の前には過去の悩みでしかありません。 型を書く。それが全てです。 型を書いて、定数を書いて、アクションクリエイターを書いて、一つ変更したら全て変更して、もしくはなんらかのハックを行って型付けして、なんてものは過去のことです。 これからは、アクションクリエイターの作成に5秒以上時間をかけたら怠惰でありましょう。そして、これはs2sの1プラグインでしかありません。 プラグインを組み合わせると以下のようなこともできます。 s2s (Source to Source) これを実現している仕組みをSource to Source(s2s)といいます。 ソースコードからソースコード

2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。

概要 ファミコンのエミュレータをJSでだらだらと作ってた。そこそこ遊べるようになったので公開しておく。技術的な内容は、またどこかで発表したり、Qiitaなどにまとめたい。（忘れないうちに。需要があるかは怪しいが。） 随分昔に作ってみたいなーと思いFPGAでの実装を開始したんだけど、早々に挫折した覚えがある。今思うとFPGAの場合タイミングの問題が付き纏うのでJSで書くより圧倒的に難易度も高いし、ハードエミュレータを実装するにしても前段階としてソフトウェミュレータを実装するのが定石っぽいので無謀だったっぽい。 ひとまずMapper0という基本的なカセット形式のみに対応し、スーパーマリオブラザーズがそこそこ遊べるくらいを目標とした。 成果物 github.com ファミコンのスペック MPU 6502(RP2A03), 8bit WRAM2KB VRAM 2KB 最大発色数 52色 画面解像度