CSS謝罪文 - jsdo.it - Share JavaScript, HTML5 and CSS
CSSによるインデックスされない謝罪文 CSSに本文が書いてあるので、画面上は表示されているがGoogleでのキーワード検索には引っかからない 「流出」などの嫌な単語は:beforeと:afterに「流」「出」を分けて書くことで、自然言語解析を回避 #s { p:first-child { font-weight: bold; font-size: 120%; } p:not(:first-child) { text-indent: 1em; } p:nth-child(1):before{ content: "お 詫"; } p:nth-child(1):after{ content: " び"; } p:nth-child(2):before{ content: "平素は弊社のサービスをご利用いただき、誠にありがとうございます。"; } p:nth-child(3):before{ c
Scala、sbt、playframeworkのversion切り替えツールの使いどころ - xuwei-k's blog
さて、以下の様なものがありますが Scalaのversion切り替えツール https://github.com/yuroyoro/svm sbtのversion切り替えツール https://github.com/paulp/sbt-extras playframeworkのversion切り替えツール https://github.com/kaiinkinen/pvm そもそも、なぜこういったものが必要なんでしょうか？そもそも本当に全員にこういったものが必要なのでしょうか？必要になる人は、どんな人でしょうか？実際どのくらい使うのでしょうか？などの、初心者にはとてもわかりづらいあたりの説明を書いてみます。 書こうと思ったきっかけは、以下のエントリです rbenvがすばらしすぎるので #Scala, #sbt, #PlayFramework 版をつくってみた。 が、とくにscalaenv、
MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
【AWS】非エンジニアのための初めてのAmazon Web Services 資料をまとめてみた | DevelopersIO
はじめに こんにちは植木和樹です。2013年2月2日は私がAWSに初めて触れた日で、本日が1周年となります。JAWS-UG北陸（金沢）の勉強会でアマゾンデータサービスジャパンの堀内さんによるハンズオン（実際に画面を操作しての体験会）が開かれ、そこでEC2やRDSを触れたのが初となります。 実際にはその3ヶ月ほど前から、ネットに流れてくるAWS関係のニュースをみたり、自分のクレジットカードを使ってアカウントを作ったりはしていたのですが、マネージメントコンソールを用いた操作をちゃんとしたのがこの日が初めてだったわけです。 さてAWSを始めた方の多くは、まずEC2にApache＋PHPを起動しRDSでMySQLを用意して・・・というエンジニア向けなところから入ってくる場合が多いようです。上記の通り私もその口で、それまで10年程やっていたインフラ（サーバー）エンジニアの延長としてAWSと関わり始め
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
