Wakame-vdc / OpenVNetをバックエンドにしたDockerをDockerのまま利用する手法についての提案と、プロジェクト参加者の募集です。Read less
![Dockerの改修を一緒にやりませんか](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed1553f22c716aa78885f5ecf9cc87f8996179cf/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fwakameunderthedocker-150330044221-conversion-gate01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
5時間モノの alter table が Lost connection to MySQL server during query したんだけど show processlist するとまだ動いてるっぽいから放置しとけば完遂するのかなと思ってるんだけど大丈夫だろうか、、、 2015-03-30 16:47:05 via Twitter for iPhone とりあえず show processlist してまだ動いてるっぽかったら、datadir 配下で #sql-xxxx_xxxxx.ibd な名前のファイルが育っているかどうか確認する。 タイムスタンプが更新されていればテンポラリテーブルへのデータコピーが生きてるということになるので、あとは show processlist を監視して終わるのを待てば良い。 で、終わったっぽかったら show create table を確認して変更が
roguelazer's website: beating the compiler なかなか面白かったので翻訳して紹介する。 たとえば、97%の場合において、僅かな効率など忘れるべきである。。早すぎる最適化は諸悪の根源である。とはいえ、残りの重要な3%の機会を逃すべからず。 -- Donald Knuth 計測せよ。計測するまで速度の最適化を施してはならぬ。たとえ計測したにせよ、一部のコードが残りを圧倒するまではまだ最適化してはならぬ。 Rob Pike 最新のWebサービスを主体とした技術の業界に長年浸かった我々は、パフォーマンスの問題を忘れがちである。SQLAlchemy ORMの中で行うリクエスト一つが8,9秒かかる中で、関数呼び出しひとつを3ミリ秒最適化したところで何になるというのか。とはいえ、時にはそのような最適化スキルを養っておくのもいいことだ。今回は、ある簡単な課題を最適化
新社会人になろうとしているあなたが、「デスマーチ」(=不眠不休の連日徹夜の炎上プロジェクトを想定します)という激務の壁にぶつかったときに、当記事が何らかの参考になれば幸いです。 私は約10年間、下流工程寄りの仕事に従事した後、上流工程へシフトしました。プロジェクト炎上の火消しにPL(プロジェクトリーダー)やPM(プロジェクトマネージャー・プロマネ)らが右往左往するものの、最終的なしわ寄せが「実装を担う開発現場」に来てしまう現実を、何度も目の当たりに、いや、実際に経験してきました。 根本原因の解明が必要ではあるものの、一メンバーである個人の権限ではコントロールできない要素がほとんどだったりもするわけです。今回はメンバー側の視点として、デスマーチという激務のやり過ごし方、取るべき対処について考えてみましょう。もちろんIT業界以外の「絶賛激務進行中」なアナタもご一緒に! スポンサーリンク 1.責
サイト強化はこれひとつ はやく、大きな成果へ ヒートマップ、サイト解析、ページ編集、A/Bテスト、WEB接客、パーソナライゼーション 1つのタグ設置だけで、全てノーコードで使えます。
こんにちは、白ヤギでは下手の横好き的なPythonistaのシバタアキラです。 カメリオのような複雑なオンラインサービスを開発提供していく上では、様々な開発言語からミドルウェアそしてハードウェアやモニタリングに至るまで、様々な計算技術を応用しています。開発言語自体はあくまで手段であって目的ではないので、自分たちのマインドシェアの中でも小さくあるべきと思っています。一方で、未だにvim vs emacsなんていう些細な選択肢に関しても「戦争」が起こる様に(起こってない?)なんだかんだいって、ツールというのはエンジニアにとってもデータサイエンティストにとってもとても大切なモノです。 昨年PyConJPのスポンサー(今年もやります!)をして以来、Pythonコミュニティーでコアに活動されている方々とお付き合いさせていただく機会も増え、また自分でもPyData.Tokyoというデータサイエンスに特
http://herokujp.doorkeeper.jp/events/10902
Goの勉強のため、普段からお世話になっているmotemen/ghqを読むことにした。なお、現在の僕のGoの知識はgotourを完走した程度だ。最初から現在のコミットを追いかけるのは骨が折れそうだったので、最初のコミットbad21c7df65ccefd74530d6fcc5f0707b63e0266から読むことにした。 Goのプログラムはmainパッケージのmain()から実行されるため、main.goのmain()から読む。 import { // ... "github.com/codegangsta/cli" } func main() { app := cli.NewApp() app.Name = "ghq" app.Usage = "Manage GitHub repository clones" app.Version = "0.1.0" app.Author = "motem
つい先日、とあるシステムの処理の流れと一部処理のフローチャートを付けた見積り資料を書くことになり、ちょうど良い機会だったので、MarkdownでUML図表が描ける「StackEdit」を使って、オールMarkdownで資料を作成してみた。 いやぁ、打ち込んだテキストがリアルタイムに図表化されていく様は、とても新鮮で、そしてすごく面白かった。資料が出来上がった後の達成感というか、完成した図表を見た時の感動が結構はんぱない。技術系の資料作成でこんな良い体験ができたのは初めてかもしれんな…(笑) ──と、結構感動的な体験ができるMarkdownでのUML図表作成なんだが、せっかくなのでそれの書き方を含めてもう少し突っ込んだTIPSとしてまとめておこうかと思った次第。 Markdown+UML とは? とりあえず、「Markdown+UML」というのは私の造語だ。まぁ、正確に言うなら「UML di
仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか
逆アセンブルを眺めながらネイティブコードの楽しさについて語ります。ハング・メモリリークなど、ソフトウェアエンジニアであればだれでも経験するであろう問題について夏休みの自由研究のように観察します。 簡単な食事および伊藤園からのお茶が提供予定です。 【講演者略歴】 我孫子 泰祐 大学院にて非ノイマン型プロセッサを研究し、卒業後に小さな会社を立ち上げるも諸般の事情で日本マイクロソフトに入社。その後マイクロソフト本社へ転籍。現在は Windows部門にてソフトウェア開発に従事。工学博士。 【内容(予定)】 ネイティブコードとは? 逆アセンブルからCソースを脳内生成してみよう(バグ修正の存在確認) コンパイラによる最適化を観察してみよう(デバッグビルドとリリースビルド) 関数コールの仕組みを観察してみよう(関数呼び出し規約、スタックメモリ) 森の中でメモリリークに出遭ったら(ヒープメモリの観察) 森
新しいハイブリッドアプリケーションのフレームワーク「React Native」をFacebookが公開。React.jsの書き方でOSネイティブのUIを利用可能 「FacebookではReact Nativeを以前から本番環境で使ってきた」(We've been using React Native in production at Facebook for some time now)。Facebookは、モバイルアプリケーション向けのフレームワーク「React Native」をオープンソースで公開しました。 React Nativeは、JavaScriptおよび同社がすでにオープンソースとして公開している「React」でモバイルアプリケーションが開発できるフレームワーク。Web技術を用いつつもモバイルOSのネイティブなUIコンポーネントを利用できるのが最大の特長で、これによってWebV
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く