0からRust/Wasmを使ってブラウザで動くバーコードリーダを作ってみた話 @_mkazutaka | メルカリエンジニアリング
こんにちは！Mercari Advent Calendar 2020 の3日目は、メルカリWebPlatformチーム/Software Engineerの@_mkazutaka がお送りします。普段はメルカリのウェブ周りの開発をしておりGoやPHPやTypeScriptを書いています。 メルカリでは半期に一度エンジニアのためのお祭りMercari Hack Weekを開催しています。この記事では、第2回Mercari Hack Weekから筆者が取り組んでいるRust/Wasmを使ったバーコードリーダについて紹介します。 こちらプロダクションには出してるものでありません。お願いすればプロダクションへのリリースを許してもらえたと思いますが、筆者自身が出さない選択肢を取ったのでそれも含めて紹介します。 (注釈: いくつかの画像処理の話が出てきますが、筆者は画像処理の専門家でもなければ大学院で
プレゼンテーションとドメインの分離 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/PresentationDomainSeparation.html 最も有用な設計原則に、 プログラム（ユーザーインターフェイス）のプレゼンテーション層とその他の機能をうまく分ける、というのがあります。 私はこれを発見して以来、ずっと慣行しています。 長い間これを使ってきて、いくつものメリットを発見しました。 プレゼンテーションロジックとドメインロジックが分かれていると、理解しやすい 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる（選択可能なプレゼンテーション部分で見かける） プレゼンテーション部分のコー
高速なWebサーバアプリケーションを構築するための6つの経験則 | POSTD
この記事では、Webアプリケーション（特にバックエンド部分）を構築するときにハイレベルなパフォーマンスを達成しようとするなら考慮するべき、最も一般的な原則のいくつかを取り上げたいと思います。私は、自分自身の経験から、主にPHPの世界で使われるいくつかの例、設計パターン、慣例やツールについて書きますが、ここで説明する概念は、どんな言語やフレームワークにも必ず当てはまると思います。 手短に言うと、基本ルールは次の6つです。 ルール1 . 時期尚早な最適化を回避する ルール2 . 最小限の作業で問題を解決する ルール3 . 今すぐやらなくてもいい作業は延期する ルール4 . 使えるときはキャッシュを使う ルール5 . リレーショナルデータベースのN+1問題を理解し、回避する ルール6 . 可能ならアプリケーションに水平スケーラビリティをもたせる ルール1: 時期尚早な最適化を回避する Donal
Go言語のDependency/Vendoringの問題と今後．gbあるいはGo1.5
Go言語のDependency/Vendoringは長く批判の的になってきた（cf. “0x74696d | go get considered harmful”, HN）．Go1.5からは実験的にVendoringの機能が入り，サードパーティからはDave Chaney氏を中心としてgbというプロジェクベースのビルドツールが登場している．なぜこれらのリリースやツールが登場したのか?それらはどのように問題を解決しようとしているのか?をつらつらと書いてみる． Dependencyの問題 最初にGo言語におけるDependecy（依存解決）の問題についてまとめる．Go言語のDependencyで問題なのはビルドの再現性が保証できないこと．この原因はimport文にある． Go言語で外部パッケージを利用したいときはimport文を使ってソースコード内にそれを記述する．このimport文は2通りの
ニトリのコードを見てニヨニヨする会（そして最後にニヨニヨできなくなった話） - Minecraftとタートルと僕
2015-06-24 ニトリのコードを見てニヨニヨする会 雑記 情報リンク集 ニヨニヨ はじめに ニトリのECサイトであるニトリネットがリニューアルに失敗して6日も経ってから復旧したということで、 （一部の）プログラマクラスタで騒ぎになっています。 僕の率直な感想は次のようなもの。 閉鎖状態の「ニトリネット」が6/23にサイト運営を再開、不具合の主因はCPU不足 | ネットショップ担当者フォーラム ともあれ関係者の皆さまお疲れ様でした。個人の責任問題などと短絡化することなく、粛々と原因解明と、できればぜひ知見の共有公開をお願いしたい。2015/06/23 13:40 プレスリリースでは、原因としてCPU不足を挙げています。 珍しい原因ですよね。あまり聞いたこと無いのでぜひその知見を知りたいものです。 しかし雲行き怪しく 早速、ニトリのトップページ見ている。すごい8000行の中にデバックコー
Goはオブジェクト指向言語だろうか？ | POSTD
“オブジェクト指向”の意味を本当に理解するには、この概念の始まりを振り返ることが必要です。最初のオブジェクト指向言語はSimulaという言語で、1960年代に登場しました。オブジェクト、クラス、継承とサブクラス、仮想メソッド、コルーチンやその他多くの概念を導入した言語です。おそらく最も重要なのは、データとロジックが完全に独立したものであるとする、当時では全く新しい考え方をもたらしたことでしょう。 Simula自体には馴染みがない方も多いかもしれませんが、Simulaからインスピレーションを得たとされるJavaやC++、C#、Smalltalkといった言語は皆さんよくご存知でしょう。さらにそこからインスピレーションを得たものとしてObjective-CやPython、Ruby、JavaScript、Scala、PHP、Perlなど様々な言語があり、Simulaは現在使用されているポピュラーな
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（後編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（後編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 （本記事は「伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015」の続きです） いわゆるAjaxが登場してから、動的にWebアプリ
[翻訳] Haskellで生産的になる(Pythonから移行して) - Qiita
Matthew Griffithさんのブログ記事 MECHANICAL ELEPHANT - Becoming Productive in Haskell comming from Pythonの翻訳です。そういえばProductive Programmerって本にもHaskellを使って実証実験する話が出てました。Haskellは何度も勉強しようとして途中で止まっては忘れを繰り返しているので見習いたいと思います。 最近になってようやく私は生産性を高められるぐらいHaskellに熟達してきました。そこでHaskellを学習してきた経験について、それらを忘れてしまう前に私の考えを書き留めておこうと思います。今や私はWebプロトタイピングのほとんどをHaskellで行っています。まだ普段はPythonを使い、また楽しんでいるにも関わらず、です。 Data First(データが第一) これは動的
![[翻訳] Haskellで生産的になる(Pythonから移行して) - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3cbd3d587cc2b6eb4919e2bf19324b6cf079ea3d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwSGFza2VsbCVFMyU4MSVBNyVFNyU5NCU5RiVFNyU5NCVBMyVFNyU5QSU4NCVFMyU4MSVBQiVFMyU4MSVBQSVFMyU4MiU4QiUyOFB5dGhvbiVFMyU4MSU4QiVFMyU4MiU4OSVFNyVBNyVCQiVFOCVBMSU4QyVFMyU4MSU5NyVFMyU4MSVBNiUyOSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDcwMGM5M2M0NWU1NWU1MDY3NTg5Yzc5OWIyMmU3NTY%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwSGlyb2Z1bWlUYW1vcmkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWYzZjc5NDlhNDExMDA3Yzk1YWMyZTlhODdjYWY3ZDI4%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Dda5d0b943592ba1e4abb6186fa2ffcaa)
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
スタートアップや新規事業に限った技術的負債の考え方 | F's Garage
最近のエンジニアの感覚だと、技術的負債というのを極端に嫌うケースがあるそうですね。 技術的負債とは… 行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。 wikipedia – 技術的負債 この言葉は確かにキャッチーだ。プログラムなんて動けばいいでしょという上司に楯突く時に使いやすい武器になりそうだ。 「負債」という言葉はなかなか面白い比喩である。 では少し、負債という言葉について調べてみると、こういうのが見つかる。 負債は借入金や買掛金などの法律上の債務であるとイメージされがちですが、厳密にいったらこれは間違いです。 すなわち負債とは、法律上の債務に限らず、いずれ会社が負担することになるであろう経済的負担で貨幣額で合理的に評価できるものが該当します。 http://financial.mook.to/accounti
仕事とは、プログラミングとは - mizchi's blog
これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、本腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた本人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら
世界最強のソフトウェアアーキテクト
Unityでオニオンアーキテクチャをやってみたという話です 2019/02/21 Roppongi.unity #1 https://roppongiunity.connpass.com/event/119111/ より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その
新しいことを学ぶときについて - kitak blog
新しいことを学ぼうとするとストレスがかかる。 例えば、僕にとってはiOSのアプリ開発がそれだ。新しい言語(Swift)に、これまで扱ったことのないインターフェイスのライブラリ、UI部品、レイアウトの方法、自分のやりたいことができたときは無上の喜びを感じるけれど、そこに到達するまでのひとつひとつでストレスを感じる。 昨日も、くだらないところでハマって2時間を無駄にしたり、言語仕様を理解していなくてコードを手当たり次第にいじって、そのうち「自分、センスないなー。頭悪いなー」とテンションが下がってくる。 そんな一日を過ごした翌日は、驚くほど理解が捗ったり、実装がうまくいく。本を読めば「あぁ、昨日のあれってそういうことだったのか」とストンと落ちるし、自分のやりたいこともすんなりできる。 確か、「情熱プログラマー」か「アプレンティスシップ・パターン」に、ロッククライミング初心者に対する指導を例に似た
多くの若きプログラマたちが学ぶべきこと | POSTD
私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
テストできないコードをE2Eテストを使ってリファクタリングしよう
ユニットテストがしにくい状態となってるコードをTestiumを使ったE2Eテストを書いてリファクタリングしてみる話です。 例えば、以下のようなjQueryで書いたコードは外(テストコード)から取り出すポイントがないので、ユニットテストを書くのは難しいと思います。(そもそもViewのコードなので) 特定のバージョンでの変更点を簡単に確認できるよう、 「Aの列のラジオボタンを選ぶと同じ行より一つ下にあるBの列のラジオボタンを自動で選ぶ」 という補助機能 $(document).ready(function () { // seq: シーケンス番号 $.each(["new_version", "old_version"], function () { $("input[name='" + this + "']").each(function (idx, elem) { if (idx == 0
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
