bliki: Value Object
When programming, I often find it's useful to represent things as a compound. A 2D coordinate consists of an x value and y value. An amount of money consists of a number and a currency. A date range consists of start and end dates, which themselves can be compounds of year, month, and day. As I do this, I run into the question of whether two compound objects are the same. If I have two point objec
bliki: Anemic Domain Model
This is one of those anti-patterns that's been around for quite a long time, yet seems to be having a particular spurt at the moment. I was chatting with Eric Evans on this, and we've both noticed they seem to be getting more popular. As great boosters of a proper Domain Model, this is not a good thing. The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing
大失敗した設計、そしてドメイン駆動設計の基本に立ち返る – 福地春喜のブログ
※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある３層構造です。何を見直して再設計するのか？それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く？本当に？ 開発対象のシステムはある情報の検索
Kubernetesアプリケーションの開発、デバッグを高速化するツール、Telepresenceの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Necoプロジェクトのsatです。 本記事ではKubernetes(以下K8sと記載)アプリケーション(以降アプリと記載)の開発を高速化するツール、Telepresenceを紹介します。 最初に結論を書いておくと、Telepresenceは次のようなツールです。 ローカルで動くプロセスやコンテナをk8sクラスタの中で動かせる 既存のDeployment内のコンテナを上記ローカルコンテナで置き換えられる テストやデバッグのためにいちいちコンテナイメージをレジストリにpush,そこからpull…とする必要がないので開発速度が上げられる Telepresenceは現在Cloud Native Computing FoundationのSandBoxプロジェクトです。 Telepresence登場の背景 前節において"開発を高速化する"と書きましたが、まずはTelepresenceを使
PHP End of Life (a reminder)
As of December 2018 PHP 5 and 7.0 became End of Life. It is now July 2019 and up to 74% of PHP powered sites in the top 1 million are running software that is End of Life. This means there is no support and more importantly if new vulnerabilities are discovered, there will be no security fixes released. Upgrades do take work and major updates can take even more work. People are busy and the reluct
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
Microservicesでなぜ作るのか - An Epicurean
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
自社とのマッチングを見極めるために––理想のエンジニア採用を実現するために大切なこと
キーマンを見つける 市古明典氏（以下、市古）：一方で、ここにもエンジニアの方はいらっしゃると思いますが、忙しくて人事の仕事を手伝うところまでなかなか回らないということもあるかと思います。また、人事の方からすると、（エンジニアから）「忙しいから」と言われてなかなか協力が取れないと思っている方がいらっしゃるかもしれません。 エンジニアの方を採用に巻き込む方法についていかがでしょうか？ 松尾奈美氏（以下、松尾）：何をするにしてもやはり一気に全員にお願いするのはなかなか難しいです。なのでリストを見る中で、「よし、この人にお願いしに行こう」という感じでターゲットを定めて、「一緒にやりましょう！」という。それに尽きるかなと思います。 エンジニアの方の中にも、自分たちの取り組みを外に伝えたり、一緒に働く仲間を自分の力で採用したい方もいらっしゃいます。その仲間をいかに作っていくかという感じでやっていました
現場の技術を知らずに研究するコンプレックスについて - 人間とウェブの未来
僕は大学時代に研究を続けたかったのだけど、当時アルバイトとして働いていたレンタルサーバー会社の中の取り組みがとても高度に思えて、こういう状況を知らずに研究を続けるのは怖いと思って、大学院に行かずに就職した。そして、3年後になんとか大学院に再び入り直すことができたし、博士課程での研究では随分と会社で学んだ運用技術をネタにした研究をすることができた。 これまで、僕は運用技術をネタに研究をやってきたのだが、研究に専念すればするほど、その経過時間だけ新たな運用技術の時代背景や細部も変化していき、それを個人としてうまくキャッチアップして研究につなげていくことが非常に困難であることに数年前から気づき始めた。でも、自分自身はそれを素直に受け入れることができず、どうにか自分の現場の経験があることを武器に研究をすることにこだわっていた。しかし、それも誤魔化しきれない程に、少しずつ少しずつ限界が来ていたし、自
Google退職します｜xyx
2019/3/15が最終出社日でした。インターン期間も含めると4年ちょっと勤めたことになります。 ちょうど昇進してプロジェクトも一区切りついたタイミングで他にすごくやりたいことができたので転職という形です。 素晴らしい環境なのに情報が少なくて、入ると良さそうなのに敬遠している人を何度か見たので、この記事が参考になれば幸いです。辞める人が言うのも変な話ですが。 あと、IT業界は最近良くなりつつあるものの、世知辛い話が世の中に溢れていて、ポジティブな話があまりないというのも悲しく感じていました。日本でエンジニアとして2000万円稼げる環境があるというのを知ってほしい。いずれ海外に行ってみようかと考えている場合の第一歩としてもかなりオススメです。 何してたの? いわゆる(ソフトウェア)エンジニア(社内用語だとSWE; “すうぃ”と読む)です。 たまに勘違いしている人がいて悲しいのですが、Goog
Dockerでアプリケーションを配布する場合に、(一部界隈で)デファクトスタンダードになっている設定項目を環境変数とするパターン - Qiita
なにかしらアプリケーションを開発しており、公式のDockerイメージを配布する。最近よく見かけますね。 利用者側の意見として、アプリケーションの設定には環境変数が使えると助かったりします。 なんで？ ADD/COPYがいらない 変更のたびビルドしなくていい Mountつかわなくていい Mount用のファイルを管理しなくていい docker-compose.ymlなどで完結 で、この環境変数からアプリケーションの設定というやり方、一部界隈のDockerイメージで命名規則が次のように、 {アプリケーション名}_{ディレクティブ}_{サブディレクティブ} {アプリケーション名}_{設定項目名} という感じの環境変数をUppercaseでアプリケーションに渡せば、設定ファイルの同じ項目を指定・または上書きするというルールがあります。 別にどんなイメージでもこうすればよいという主張ではなく、なんかし
GitHub経由で海外から仕事が来た話｜shu223
この記事は、2015年に自分のブログに書いたものですが、今もフリーランスとして海外から仕事を受けるときのスタンスはあまり変わらない（英語での調整は大変だし海を隔てて互いに信頼を確立するのは大変なので、それが自分的に勉強したい分野であるという前提で「成功報酬型」を提案する）ので、noteに移植してきました。 --- はじめて海外から（フリーランスとして）仕事をいただく、という貴重な経験ができたので、その経緯などを書いてみたいと思います。 きっかけ7月末のある日、知らないメールアドレスから英語のメールが来ました。内容を一部だけ抜粋すると、 We are looking for someone to develop a very simple apple watch app and a companion apple phone app.というわけで、Apple Watch アプリをつくって欲し
On "Open" Distros, Open Source, and Building a Company
Search and analytics, data ingestion, and visualization – all at your fingertips.
OSSライセンスMeetup Vol.2「実録：GPL違反とその対応を振り返る」参加レポート | gihyo.jp
OSSライセンスMeetup Vol.2「実録：GPL違反とその対応を振り返る」参加レポート 2019年2月21日（木）に開催された「OSSライセンスMeetup Vol.2「実録：GPL違反とその対応を振り返る」の参加レポートをお届けします。少しでもMeetupの雰囲気や魅力をお伝えできればと思います。 OSSライセンスMeetupとは その名の通り OSS（Open Source Software）のライセンスに関するテーマを扱うMeetupです。エンジニアに限らないさまざまな人に向けた「OSSライセンス」についての啓蒙や参加者間での知見の共有のための場という、ありそうでなかったMeetupです。 今回はGPLに主な焦点を当て、前半は日本国内でGPL違反事例として語られるプロジェクトで当事者となった会社に在籍していた宮田晃佳さんを迎えて、状況や経緯、解決策、対応後の反響などについて振り
システム障害との向き合い方 @sinamon129 #tokyogirlsrb
これまで大小様々なシステム障害に遭遇してきましたが、障害対応から学ぶことは沢山あります。 いろんな習熟度のフェーズで障害発生を学びに変えるための行動事例や、webアプリケーション開発において障害対応を減らすためにできることなどをお話しできればと思います。 TokyoGirls.rb Meet…
Azure DevOps について - Qiita
MS(Microsoft) が VSTS(Visual Studio Team Services) をリブランドして、Azure DevOps というサービスにしたそうです。 DevOps まわりのツールがひとまとめになっていて結構便利そうな感じですので、ちょっと見ていきたいと思います。 そもそも VSTS って何だったのか VSTS は Visual Studio Team Services といい、元々 Visual Studio という MS の開発ツール群をチームで使っていくためのプラットホームでした。 おおまかには Azure DevOps と変わらない機能を提供していましたが、MS が Github を買収したことによりどう統合していくかが話題になるようなものでした。 で、その結果が Azure DevOps というところなのだと思います。 VSTS 今は、VSTS のページに
ネットを手に入れた中国が 「世界の検閲官」になるとき
When Chinese hackers declared war on the rest of us ネットを手に入れた中国が 「世界の検閲官」になるとき 多くの人がインターネットは中国に民主主義をもたらすと考えた。だが、実際には中国は世界を検閲しようとし始めている。 by James Griffiths2019.02.27 75 37 8 0 2015年3月のある水曜日の夜遅く、サンフランシスコに本社を置くソフトウェア企業、ギットハブ（GitHub）のオフィスに警報が鳴った。シリコンバレーから始まり、いまどきのオフィスに広く受け入れられた北欧風の内装。つまり無垢の木材、固定壁を使わないオープンスペース、豊富な自然光を取り入れたのが、ギットハブのオフィスだ。ほとんどの従業員は帰宅の準備をしていたが、すでに帰った人もいたかもしれない。外を見れば太陽が沈み始めており、さわやかな晴れた日だった
Testing with YAML
YAML のテストについて Policy as Code の考え方を取り入れて Sentinel のようにテストするツールを作った
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
（採用担当者向け）エンジニア採用をする上での基礎知識 / recruting_engineer_basic
