数日前に、とみたまさひろさんのこんなツイートがありました。 なんだこれ? MySQLこわい… mysql> SELECT * FROM x WHERE datetime IS NULL; datetime 0000-00-00 00:00:00— とみたまさひろ (@tmtms) 2015, 12月 17 @tmtms ちなみにその '0000-00-00' は、 IS NOT NULL のときには含まれないんですか?— 坂井 恵(SAKAI Kei) (@sakaik) 2015, 12月 17 MySQL :: MySQL 5.6 リファレンスマニュアル :: 12.3.2 比較関数と演算子 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます" その後の t
Conventions - 規約 General Conventions - 一般的な規約 Document the complexity of any computed property that is not O(1). People often assume that property access involves no significant computation, because they have stored properties as a mental model. Be sure to alert them when that assumption may be violated. 計算量がO(1)で無いcomputed propetyには、複雑度をコメントに記述してください。 我々は、プロパティアクセスは大量の計算を伴わないとしばしば想定します。 なぜなら、普通プロ
概要 このへんの本を読んで復習がてらに書いてく 計算式 (物理RAMの合計) ― {max_connections x (スレッドバッファによる消費) + グローバルバッファによる消費} > 0 グローバルバッファ + スレッドバッファで消費されるであろうメモリサイズが物理メモリサイズを超えないようにする 物理RAM:r3.2xlargeで61GB グローバルバッファ(サーバ全体に設定されるオプション) すべての接続とクエリに影響する mysqldが獲得できるRAMの量を計算し、バッファサイズの合計がこれを超えないようにする オプション query_cache_size innodb_additional_mem_pool_size innodb_buffer_pool_size innodb_log_buffer_size key_buffer_size 消費メモリ計算式(GB表示) S
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう?と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
おそらく一生で最初で最後の「ひとりアドヴェントカレンダー」を完走した記念に、自分の日記のところでもカレンダー形式のリンク集を作って見ました、、、、、が、単純にはてな記法するだけだと崩れまくりです(^^; まぁいいや。 完走記念(というわけではありませんが)1月半ばに福岡で sakaikを囲む会(通称さかいかい)やります。福岡のみなさん、あそびましょ!呑むだけですが。 2015年12月:アドヴェントカレンダー「MySQLマニュアルを読む」 30 1MySQLのリファレンスマニュアルを読もう 2MySQLリファレンスマニュアルのURL 3MySQLマニュアルの「チュートリアル」 4MySQLの数値数学関数いろいろ 5MySQLマニュアルより「制限事項」 6MySQLマニュアルから「型」いろいろ 7MySQLの文字列関数はこんなにある 8MySQLで使うファイルフォーマットも書かれているマニュア
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム(16年の歴史があります)の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く