はてなブックマーク

function main() { (async () => { try { const response = await fetch('/cms/api/csv/upload', createFetchPostData()); const json = await response.json(); console.log(json); } catch (error) { console.log(error); } })(); } function createFetchPostData(data = {}) { return { method: 'POST', // *GET, POST, PUT, DELETE, etc. mode: 'cors', // no-cors, cors, *same-origin cache: 'no-cache', // *default, no-ca

エリック・エヴァンスさんが提唱しています。 QCon Tokyo 2011 アーキテクチャパネルディスカッション＋DDD雑多ネタ 上記記事を見て、僕も思うところを書いていきます。DDD系の話は、議論になったりすることもありますが、１エンジニアのつぶやきと思ってみてください。（文中の引用文は、上記記事から引用させていただいています。） 基本概念 作成するシステムのプログラムコードと、ドメイン（現実の業務）が一致することによって、 主にコアドメインへの注力によって競争上の優位、市場優位につなげる という。 ドメイン駆動設計を実践するための方法 レイヤードアーキテクチャ ドメインロジックと、それ以外（DBやViewなど）を切り離すのが目的 最近のシステム設計もレイヤードアーキテクチャを採用していたりするので、DDDじゃなくても採用したほうが良いと思っています。 ドメインはオブジェクト指向言語が表

掲題の通り、MongoDBのベストプラクティスのPDFを読んだメモです。 Linuxの設定系 ファイルシステムのatime設定（アクセス時間機能）を無効にすること WiredTigerの場合、xfsのファイルシステムがストロングレコメンド raid組むなら0 or 10を推奨 LinuxのHugepageの機能はオフにすること Mongo系 ジャーナルファイルとデータファイルを別々のストレージに保存すると、パフォーマンスアップする GCPでは通常のSSDを使う場合は一緒で良いと言っています（おそらく容量によってストレージパフォーマンスが変わるため、分けないほうがコスパが良くなるのかと。） インデックスとコレクションを別々のストレージに保存できる Zone機能でシャーディング分割できるから、RDBMSのパーティション的なことを出来る directoryPerDBを使えば、DBごとに使うディス

PHP7のインストール これを書いた理由 最小の設定と構成で、phpが動くインストール手順がほしかったので、書きました。apacheのセットアップなど面倒な手順を省きたかった形です。 事前準備 Visual Studio 2015 の Visual C++ 再頒布可能パッケージ これを、windowsの32bit or 64bitを合わせつつ、ダウンロードしてインストールしてください。 ダウンロード編 公式ダウンロードページから、ダウンロードしてきます。 とりあえず試してみたい場合、windowsの32bit or 64bitを合わせつつ、スレッドセーフ版を選ぶと良いと思います。 Webサーバを別で起動する場合 apacheでマルチスレッドに動かすなら、スレッドセーフ nginxでシングルスレッドに動かすなら、ノンスレッドセーフ を、選びます。 このセットアップでは、PHPを単品で動かしま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 僕の本職はサーバーサイドなのですが、半年くらいReactとReduxを使ったフロント部分を触ったので、書きたいと思います。 先にReact.jsについてですが、本家がチュートリアルをしっかりと用意しており、学習コストも高くなく、悪くないものだなと思いました。 しかし、Reduxが入った途端、めっちゃ複雑になった印象があります。chromeのプラグインを入れて開発するのが普通とか言われたのですが、そんなものを使わないと作業できないくらいに複雑で辛いなぁという印象です（Javascriptは、console.logがあれば、ほぼ開発できる気

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 10年くらいエンジニアやっています。その中で、開発が炎上したなぁとか、うまく行ったなぁとか、振り返ってみると実力以外のところに要因があったことも多かったので、そのへんを書きたいと思います。 人によっては、違うと思われる方もいると思いますが、1エンジニアの所感と思ってくださいm(_ _)m 火種達 リテラシの低さによる無茶振り 開発途中の品質チェックを細かく出来ていない マネジメント側のキャパオーバー マネジメント側がエンジニアの言った工数で必ず出来ると捉えてしまう 作業者のモチベーションの欠落 作業者の実力不足 経験上、ざっくり上げると

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

理由 「集中できる開発スタイルを目指して」で、書いたのですが、仕様書をmarkdownでコミットするようになって、リアルタイムで表示を確認したいと思ったため、使い始めました。 良い所 何も入れずに、デフォルトでマークダウンがプレビュー出来ます。 カスタマイズしなくて良いのは、本当に良いですね＾＾ レスポンスも遅いと言われている割に、個人的には余裕で許容範囲だと思います。 悪いところ フォントの設定をしても、プレビューに反映されません。そちらは別途設定する必要がありました。 AtomでカッコよくMarkdown PreviewするためのCSS 小ネタ Ctrl + Shift + Mで、今開いているファイルのマークダウンプレビュー出来ます。 まとめ Markdownのためだけに、Atomを使うのはありだと思います。 エディタ戦争とかありますが、全部１個で担うのではなく、要所要所で 最適なもの

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

トランザクションがコネクション切断時とかに、どういう挙動を示すか？調べてみました。 PHP＆MySQLのトランザクション関連の仕様ざっくりと デフォルトでは、すべてのSQLがトランザクションを使用し、オートコミットする。（updateしたら即反映） 明示的に、beginTransactionした場合、そのコネクション上で行われた更新は、commit or rollbackメソッド実行時に一括で反映される。 また、beginTransaction中に接続が切断された場合、rollbackする。 http://dev.mysql.com/doc/refman/5.6/ja/innodb-implicit-commit.html 他のRDBMSだと、コネクション切断時はデフォルトcommitだったりするときもあるので、挙動は確認したほうが良いと思います。 暗黙的コミットにも気をつける 13.3.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 新技術の話をしたときに、僕がいつも話すことをまとめてみました。気になるところとか、突っ込みどころがあれば、コメントいただきたいですm(_ _)m 技術選定時に気を付けること 現場に残る人たちが使いこなせるのか？（選定した人が抜けても機能するか？） ブラックボックス的に使うなら、十分に枯れているか？（10年以上が節目？） シンプルさや、使用感の統一性、既存技術との乖離性（手続き型と関数型など）などを考慮 高負荷時の動作など大丈夫なものか？（高負荷になるとバグが出たりします。。。） 既存技術と比べて大きな優位性があるのか？ 頑張って選んでも

ダメな理由（JavaScriptの場合） 古いIEだとエラーになる。 正式なJSON形式だとエラーになる。 システムとしては、動かなくなるのが最悪だと思うので、それに繋がる書き方はダメだと思います。 それ以外も考えてみた ダメな理由だけで十分使いたくないが、それを超えた嫌な気分があり、 どうしてだろうなぁと、昨日エンジニア同士の飲み会で話していた。 僕の思うところ Javaのオートボクシングとか、シンタックスシュガーとかもそうですが、予期しない動作をすることがある書き方や設定で、痛い目を見た経験があるので、嫌な気分になっているのだと思います。 DBとかもゆるふわで設定していて、変な値が入って痛い目を見るとか。結局、振れ幅のある書き方をすると、予期しない動作をする可能性があり、結果障害に繋がることがあるのが、嫌なのだと思いました。 余談ですが、MongoDBなどは2系で許していたゆるふわクエ

個々のコマンドの説明とか、Gitの記事はたくさんあるので、細かい話はしないです。僕がいつも説明するときに言っていることをまとめて、説明時間を短縮する目的の記事です。 （今更Git記事書くなよとかあると思いますが、そこはご容赦ください。） 対象者 ある程度、SVNなどをやっている人向けなので、説明が足らないところや省かれているところがあります。そこは適宜ググッて頂きたいです。（キーワードでググれば大丈夫かと） 僕のGit歴 説明するとか言いながら、Git初心者野郎だった。とかだと嫌だと思うので経歴です。 Git歴2年以上 Git移行委員会とかやったことある BFGとか使って、大きなバイナリファイル削除したりした SVNからGit移行とかもやったことある GitとGithubは違うもの プルリクエストの機能はGitには無く、Githubの機能です。なので、gitコマンドではなく、hubコマンド

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ちょっと、簡単に答えられなかったので、休み中にまとめました。 「どこまで勉強すれば良いか？」 という質問には、 自分の立ち位置や、今後の目標など関わるので、 それらを踏まえて考える必要があると思います。 職種によっても違いますが、質問された時の状況は、 Web系エンジニアが新卒の子に聞かれた形なので、 考慮いただきたいです。 また、そもそも、どんな背景をもったやつが書いてるんだ？と思う方も いらっしゃるかと思いましたので、簡単に自己紹介してから書きます。 書いている人の自己紹介 現在33歳で、エンジニアスタートしたのが、 2005年08

僕の作業時間 プログラミングだけに限定して、総量を10とすると、 5 : Laravel 2 : PHP 3 : 業務ロジック となります。 本質的に作りたいのは、業務ロジックなので、 7 : 業務ロジックくらいにしたいです。。。 フレームワークの示す道 フルスタックフレームワークは、ちょっとでも道を外れると、 フレームワークのマジカルファンシーなソースコードを追いかけて、 そこに対応するマジカルコードを書かなければならず、 そこで膨大な時間を消費します。。。 Webアプリケーションで必要なものはそれほど多くない気がする シンプルなORM（発行されるSQLがコード読むとわかるくらいの） httpのルーティング部分（Controller層担当） View層のFW ログのFW テストFW 便利メソッドの集合体（必要なければ要らない） ぱっと思い浮かぶ感じ、こんなところでしょうか？ 各々、個別に