カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
シャイニングなホテルに泊る :: デイリーポータルZ
映画「シャイニング」が好きだ。初めて見てから今まで、1ヶ月に2、3回のペースで見ている。のべ回数にすると200回以上。それだけ見ても全然飽きない。夜中に酒を飲みながら暗い部屋でシャイニングを見る。誰にも邪魔されたくない至福のひと時である。 そんな「シャイニング」の舞台はコロラド州の山奥、冬期だけ閉鎖されるホテルであるが、その舞台設定が素晴らしい。普段は沢山の人たちで賑わうホテルから誰もいなくなって、周りは深い雪に囲まれて、通信手段は無線のみ。さういうものに私は惹かれる。そして、ふと思った。 日本にも冬期閉鎖されるようなホテルはあるのだろうか？ ネットで検索をかけてみると、そういうホテルがいくつか出て来た。その中で最も「シャイニング」的なロケーションだったのが、富山県は立山にある「ホテル立山」である。このページを見てもらいたい。「ようこそホテル立山へ」。標高2450m、日本一高い場所にあるリ
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
[プログラミング]よいコードを書くために - logiqboard
コードをたくさん読んでいると、よくできていて参考にしたくなるコードや、身の毛もよだつクソコードなど、色んなコードに出会う。 自分一人で書いていた頃は、コードの良し悪しは全て自分にはね返ってきていたのだが、チームを組むとそうはいかない。 人の書いたコードで苦しむこともあれば、自分の書いたコードで人を苦しめることもある。 そんなことにならないよう、少しでも良いコードを書くために意識するべきことをまとめてみた。 読むのに苦労しないコードを書く 書かれたコードは、それが使われ続ける限り、何度も読まれる。 読む人は自分かもしれないし、他のチームメンバーかもしれない。別の会社の顔も知らない人かもしれない。 そんな人たちでもスラスラ読み解け、理解できるコードは、きっと良いコードだ。 冗長さを制御する 大体の悪いコードは長い。どんなに素晴らしい設計がされていても、長いと読む気力が失せる。コードは短いに越し
![[プログラミング]よいコードを書くために - logiqboard](https://cdn-ak-scissors.b.st-hatena.com/image/square/824a64f5ea8b1fa29b6b1ff45aabef6b5568bc85/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127144886642%2F17680117127144886906%2F1558210211)
欧州委員会、「忘れられる権利」のプライバシー規定案を公式説明
欧州連合（EU）の欧州委員会（EC）はベルギーで現地時間2010年11月30日、プライバシー保護の新たな規定案について公式説明を行い、ユーザーの「忘れられる権利」の重要性を強調した。 ECは11月4日に、プライバシー保護対策の強化に向け、1995年制定のデータ保護指令（EU Data Protection Directive）を見直し、ユーザーの「忘れられる権利」を盛り込んだ新たな規定を導入する意向を明らかにした（関連記事：ECがプライバシー保護の新規定案、「忘れられる権利」をユーザーに）。データが不要になった場合あるいはデータを消してほしい場合に、ユーザーが削除を要請する権利を持ってしかるべきだとしている。 また同規定案では、個人情報の収集と使用を必要最小限にとどめること、個人情報が、誰によって、どのように、何のために、どれくらいの期間収集および使用されるかをユーザーに通知すること、また
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Functional Programming
コンセプトから理解するGitコマンド