KMC春合宿2018での発表資料です
2018年の”JavaScript” 再入門/re-learning-about-js-in-2018
KMC春合宿2018での発表資料です
もう管理画面のフロントコードを書く必要はありません、そう Viron ならね。 - Qiita
管理画面のフロントエンドコードを書く時代は終わりました。 Vironがあれば、OpenApi(Swagger)でAPI定義を行い、実装するだけで管理画面が完成します。 そしてこれはOSSです。誰でも自由にお使いいただけます。 概要 Vironは、複数の管理画面を管理できるよう設計された、管理ツールマネージメントコンソールです。 APIサーバーとOAS2.0 jsonファイルを作成するだけで、管理画面が一つ完成します。 経緯 私の会社では、大小さまざまな自社サービスが開発・運用されています。 管理画面をサービス・サイト毎に作っていましたが、それには限界がありました。 エンジニアからしたら、管理画面用のデザインやAPIを作らなきゃいけない。工数がかかる。 運用・プロデューサーは、UI・UXが管理画面で違うため、操作を覚えるという学習コストが高い。 さらに外から見たいときにスマホから見れないし、
1行直すだけってそんなに大変なの？
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
読んで良かった基礎知識の入門書
とあるエンジニアの技術勉強法 (インターン学生向け) というスライドを先日 @iwashi86 が書かれていました。 インターン学生向けとありますが、新人プログラマ向けとしても素晴らしい資料だと思います。 ここでは「即、役立つわけではないが後から効いてくる」という「基礎知識」に絞って教材を紹介します。 目の前の仕事のために必要なことと並行して基礎知識を学ぶのは、長期的には良いと思います。 なお「基礎」==「簡単」というわけではなく、無理せず自分のペースで付き合うのがおすすめです。 自分で読んで、かつ、とても良いと思ったもののみを紹介するので、全分野をカバーしてはいません。 基礎にどのような分野があるかは新卒準備カレンダー2011や情報科学科カリキュラムが参考になります。 以下はどれも有名な本なので、ググれば感想なども見つかるでしょう。 気になった本、読もうと思う本については、ググるのも良い
第一回 PHP Wayを開催しました - PHPから別言語に変えることを考えた振り返り - BASEプロダクトチームブログ
BASE本社で12月19日にPHP Wayというイベントを開催しました。 PHPで成長したWebサービスを他の言語に移行させる話題を見ることがありますが、PHPを使い続ける企業がどのようなことを考えて、その選択をしているのか？ということを共有するイベントでした。 どこか自信を見失いがちなPHPの利用について、適切に状況判断するための材料を共有し、PHPを使うサービスにエンジニアとして関わっていくにあたって無駄に悲観的に思わないようにするのをイベントのゴールとして設計しています。 （左からコネヒトCTO島田さん、BASE藤川、サイバーエージェント SGE CTO 白井さん） BASE社の発表資料はこちらです。 20171219 / phpway / BASE,Inc. from 真一 藤川 一度採用した開発言語、実行環境やフレームワークは、一定のライフサイクルの後に、それを採用していることそ
Cutting Edge - 一般的なアプリケーション向けの CQRS
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 一般的なアプリケーション向けの CQRS Dino Esposito ドメイン駆動設計 (DDD) は約 10 年前に登場し、ソフトウェアの開発者やアーキテクトに影響を与えています。具体的なメリットやデメリットはともかく、DDD は、オブジェクト指向パラダイムが初めて唱えられた頃、開発者の誰もが夢見たことを具体化します。つまり、包括的なオブジェクト モデルを中心にアプリケーションを構築して、すべての関係者の要件や懸案事項に対処するという夢です。 その後の 10 年、多くの開発者が DDD のガイドラインに従うプロジェクトに取り組んできました。成功したプロジェクトもあれば、失敗したプロジェクトもあります。実は、
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」 | POSTD
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
CQRSの和訳
DDDとCQRSについて DDD (Domain Driven Design = ドメイン駆動設計)が世間に知られるようになってきましたが、今度はDDDをさらにスケーラビリティにするCQRS (Command Query Responsibility Segregation = コマンドクエリ責務分離)が出てきました。 DDD提唱者の英語本の和訳版「エリック・エヴァンスのドメイン駆動設計」がAmazonにありますが、非常に分厚く高価です。概要をまとめた資料が「Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 - InfoQ」から入手できます。 CQRSはデータベース設計とイベントソーシングも含めた壮大なWebアプリケーションのアーキテクチャですが、日本語の資料がまだ少ないです。CQRSを適用したアプリケーションを構築できるインフラがWindows Az
やはりお前らの真偽値メソッド名は間違っている。 〜「Xxx できる？」系メソッドの命名〜 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 晒すつもりではありませんが、Facebook で友人のとある投稿を見かけて最初は「三単現にしないと💢」という軽い気持ちで返答したのですが、よくよく考えて見たらこれ思った以上のクソ命名でしたので、とりあえず流れのスクショを上げときます： はい、今回の記事はマサカリです。あしからず。 見ての通り、最初は友人の後輩ちゃんが isCanUseSkill という明らかにアレな命名をしてきたので、友人がそれを指摘をするも、まさかの allowSkill という更にダメな名前をつけてきた件。isCanUseSkill はまだ「なんだこいつの英語はｗ
ドメイン駆動設計のための Spring の上手な使い方
10. 学んだことをコードで表現する • ドメインの知識をコードで表現する基本スキル • 値オブジェクト、コレクションオブジェクト、区分オブジェクト • 識別オブジェクト、集約 • Repository, Factory • 知識の増加がコードに現れる • パッケージ名、クラス名、インタフェース名、メソッド名 • 洞察の深さがコードに現れる • パッケージの構造、オブジェクトの参照関係、… • コードレビュー：ドメインの学習成果のレビュー • パッケージ名、クラス名、インタフェース名、メソッド名、… • 参照関係／グルーピングの範囲 • コードで表現されたドメインの知識の量は？ 質は？ • コードでの知識表現に工夫の余地は？ 10 技術者はエクセルで知識を表現してはいけない
ビジュアル・プログラミングの勉強方法｜深津 貴之 (fladdict)
ビジュアルアートの教本、「Generative Design」が、ついに再販されました！長らく欠品でプレミアムがついていた一品です。 以下はGenerative Designの序文への寄稿を、一部加筆修正したもの。表現者、技術者それぞれが、アートとプログラミングを学ぶための方法です。ビジュアルコーディングに興味のある人はどうぞ。（あと僕の落書きはこちらから見れます） Generative Design 序文Generative Designの日本語版が、いよいよ出版されました。本書は、プログラミングによる視覚表現の「最高の教本」です。この素晴らしい本の序文として、何を書くべきか非常に悩みました。結果として、歴史やカルチャーの話をするよりは、この本の読者に最も役に立つであろうことを、書くことにしました。表現者と技術者がビジュアル・コーディングをどう学習すべきか、についてです。 表現者が技術を
差分検出アルゴリズム三種盛り - Object.create(null)
こんばんは. 気がつけばもうずいぶんと涼しくなってきました. 勢い余って凍ってしまったりせぬよう, くれぐれも普段の言動にはお気をつけください. はじめに さて, 我々人類にはどうしても二つの文字列 (あるいは行ごとに区切られたテキスト) 間の差分を求めなければいけない瞬間が発生します. 先人たちはそういった時のために diff のようなツールを開発し, それを利用することで文明はめざましい発展を遂げてきました. しかしながら, 使用するアルゴリズムを比較検討したい場合, 「差分」の定義を変えるなどして既存のアルゴリズムに変更を加えたい場合, diff のない異世界に飛ばされて自分で実装しなければいけない時などにおいては, 差分検出アルゴリズムについての理解が必要不可欠です. というわけで, この記事では文字列間の差分検出とは何かということと, 差分を求める三種類のアルゴリズムの紹介・解説
Java9 でも String クラスがリファクタリングされていました （JEP 254: Compact Strings 編） - 地平線に行く
本日、ついに JavaSE 9 がリリースされました！ そこで、かねてから噂になっていた JEP 254: Compact Strings がどのように実装されているのか調べてみました。 Compact Strings の概要 これまで String クラスや StringBuilder クラスなどの内部では、文字列を UTF-16 でエンコードして char 配列で保持していました。 つまり、一文字あたり*1常に char ひとつ = 2バイト分のメモリを使っていました。 しかし、これだと 1 バイトで表せる LATIN1（ASCII コード ＋ ラテン文字）の文字列の場合、その半分が 0x00 になるという無駄がありました。 そこで、内部表現を変更し、文字列が LATIN1 のみで構成されるときは 1 文字を 1 バイトで保持するようにリファクタリングされました。 ちなみに、LATIN
PyQ - 本気でプログラミングを学びたいあなたへ
必要なのはブラウザだけプログラミングを始める時に、最初につまづくのが環境構築です。 PyQでは環境構築なしで、ブラウザをひらけば10秒でプログラミングを始められます。 読む・書く・動かすサイクルで定着PyQのエディター画面では、実際にブラウザの後ろでPythonが動いています。これにより、教材を読む→コードを書く→実際に動かすという流れを画面内で完結できます。もちろん、自分で内容を変更して、動かして試してみることもできます。 あなたの興味に寄り添う、1500問以上から選べるコンテンツPyQでの学習は、数個の問題からなる「クエスト」という単位で進みます。 600クエスト・1500問以上存在するすべてのクエストは、好きな順に学び放題。 関連の深いクエストはパート・コースにまとめられており、 直感的に様々なクエストを組み合わせて、自分の興味のある分野を学べます。
Linux シグナルの基礎
TLPI (The Linux Programming Interface) 再々。 TLPI の輪読の際に @matsumotory よりシグナルセットあたりをまとめるようにと指令が出たので、拙遅な感じでまとめました。 シグナルとは プロセス間通信の一種。「プロセスにシグナルを送信すると、そのプロセスの正常処理に割り込んで、シグナル固有の処理(シグナルハンドラ) が実行される」プロセス側では、シグナルを受信した際の動作(シグナルハンドラ) を設定することや、シグナルをブロックすることも可能。 コンソールで、プロセスを終了させるためにkill -9 <PID>とかCtrl+Cとかした際にも、対象プロセスにシグナルが送信されている。 ちなみに、PID「1」の init や systemd にkill -9 1しても何も起らない。(そういえば昔、oom-killer に init を殺された覚
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
return true to win
CQRSに対する批判的見解
The DEV Community
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
