Windows 10 Anniversary Update(Redstone 1)がリリースされて早くも2か月が経過しましたが、中華タブレットではまだ前ビルドであるWindows 10 ビルド 10586(Threshold 2)が適用されているケースが多く、場合によってはWindows 10の初期ビルドである10240(Threshold 1)からAnniversary Updateにアップデートしたいとか、(現在は有料となってしまいましたが)Windows 8.1 With Bingの状態からアップグレードしたいという方も多いかもしれません。 中華タブレットにインストールされているWindows OSは日本語ランゲージパックを適用することでほぼ日本語版と同様の環境で利用することもできますが、正確な意味での「日本語版」ではなく、アプリケーションによっては「日本語版OSではないため、起動不
ITには大いなる可能性と危険性があるが、結局はソフトウエアの問題に尽きる。ソフトウエアの構想、企画、設計、開発、保守のやり方をどう良くしていくのか。ソフトウエア人材の将来像はどのようなものになるのか。日本製ソフトウエアを輸出できないのか。 ソフトウエアについて様々な人が論じ合える場を用意し、多くの人に考えるきっかけを提供したい。そこで「ソフトウエア、それが問題だ~Software Matters」と題した本連載を始め、この中で、ソフトウエアの諸問題と対策を日本や世界の論客の方々、そしてITpro読者の皆様と考えていく。ソフトウエアに関するご意見をお寄せいただきたい。 第1回として米カリフォルニア大学バークレー校のRobert E.Cole(ロバート・コール)名誉教授に寄稿いただいた。コール氏は、日本の作業組織の研究で知られる。ミシガン大学社会学及び経営学の教授を務め、日米自動車の製品品質の
第2シベリア鉄道とも呼ばれたバムはタイガ(亜寒帯林)、七つの山脈、11の大河を貫き、太平洋に至る第二の出口をロシアにもたらし、へき地の資源を手の届くものにした。東シベリアと極東を通る輸送路を建設する構想は19世紀末に生まれていた。ロシア政府がそれに関心をもったのは日露戦争での敗戦(1905年)以降。東部国境の強化が必要になってからだ。それから実地調査が行われたが、第一次世界大戦とロシア革命がそれを妨げた。 完工は1984年 バム鉄道の中枢部分の建設はソ連時代の74年に始まり、84年レール敷設を完了した。以後、鉄道線を延長した。この「世紀の大建設」には約200万人が参加した。ある者はロマンを求め、ある者は高給に引かれてやって来た。彼らの多くはそのままバム鉄道沿線の都市や集落に残ったが、これらの街は90年代初めからさびれ始めた。 バム鉄道は全長約4300キロ。イルクーツク州タイシェトからバイカ
私はシリコンバレーには数ヶ月働いていたのみで、起業していたわけではないですが、スタートアップ時代、Code for America 、スタートアップ支援などの仕事で年何度かSF/SVに行ってミーティングをする中で雰囲気として感じていた事がわかりやすく書かれていたので、向こうと取引がある方は是非一読しておくと良いかと思います。ポイントだけ抜粋してみます。 Rule #1: Be On Time 約束の時間を守ること。時間通りに到着しない人は、1.有能でない 2.相手を尊敬していない 3.信用に値しない と見られてしまう。 Rule #2: Same Day Email メールを貰ったその日の内に返信をすること。早めに返信をすることで、相手のことが重要だというシグナルを伝えらえる。 Rule #3: The Double Opt-In Intro 人を紹介する/してもらいたい時は、紹介される側
8月1日から9月30日まで、大学院の同期で小学生時代は落ち着きがなかった @ganmacs と、小学校の給食ではソフト麺が出なかった @amaya382 と一緒に Treasure Data (TD) Summer Internship に参加した。 Treasure Data インターンで最高の夏過ごしてきた #td_intern - memo-mode トレジャーデータでインターンしてた話 #td_intern - 水底 インターンの途中で1週間アメリカへ行ってしまうという事情を酌んだ上で採用していただき、限られた期間で物凄く適切な課題設定とメンタリングを行なってくださった@myuiさんには頭が上がらない。本当にありがとうございました。 TDインターン全体としての見どころは、 全方位ウルトラエンジニアで気を抜くと死ぬ環境 丸の内の一食1000円オーバーの飲食店事情 ラウンジの炭酸強めで
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
最近非常にadbコマンドを利用するので、覚えておきたいコマンドをメモします。 他の方と重複する内容があるかもしれませんがご容赦ください。 コマンドについては随時追加していく予定です。 私自身既に覚えてしまっているコマンドは記載していませんが、後々整理していきますm(__)m 接続端末を確認
頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール(例:月曜開始の1週間スプリント) 会議体の設定(例:スプリント計画、スプリントレビュー、レトロスペクティブ) 複数チームのワークフロー(例:プロダクトオーナー、UXデザイナー、開発チーム、QAチーム) 仮説検証サイクル(例:仮説設定、リリース、分析) 進捗管理方法(例:リリースバーンダウン) 品質管理方法 障害対応のワークフロー プロセス改善の仕組み(例:レトロスペクティブ結果のバックログ化) プロダクトデザイン(略) ソフトウェアアーキテクチャ(略) インフラアーキテクチャ(略) テスト計画(略
Pythonは、習得が容易で、より大きく複雑なアプリケーションの開発にすぐに適用していけることから、コンピューティング環境に広く普及し、勢いを強めています。ただ、あまりに明瞭で親しみやすい言語なので、ソフトウェアエンジニアやシステムアドミニストレータが警戒を解いてしまい、セキュリティに重大な影響を及ぼすコーディングミスを誘発する可能性はあるかもしれません。主に、初めてPythonを使う人を対象とするこの記事では、この言語のセキュリティ関連のクセに触れます。ベテラン開発者にとってもその特異性を意識するきっかけになればと思います。 入力関数 Python 2に多数存在するビルトイン関数の中で、 input はセキュリティの面で完全に難点です。この関数をひとたび呼び出すと、標準入力から読み込んだものが即座にPythonコードとして評価されます。 $ python2 >>> input() dir
最近Reaktorが掲載した『 Promises made by a Reaktor developer had an impact on the industry article 』で約束した、Bluebird promiseライブラリの製作者であるプログラマのPetka Antonovからの知見です。 Bluebirdは広く使用されているJavaScript用のpromiseライブラリで、同じような機能が実装されているにも関わらず、他のpromiseよりも100倍速いという理由から最初に知られるようになったのは2013年でした。Bluebirdが高速な理由はライブラリ全体にJavaScriptの最適化の基礎を一貫して適応しているからです。この記事ではBluebirdの最適化に使用する3つの重要な基礎について詳細に説明します。 1. 関数オブジェクトの割り当てを最小限に抑える オブジェク
Dockerとは コンテナベースのアプリケーションを仮想化したもの。軽量なVMの様に見えるがこれまでの(VirtualBoxなど)VMでは実現が難しい、不可能であったユースケースを解決してくれる。 ホストOSとリソースを共有するのでリソースの管理がVMより効率的 基本的に状態を持たないのでポータビリティが非常に高く、特定の環境に依存することがない 軽量なのでVMと比較し複数のインスタンスを実行することができる DockerHubなどのレジストリを利用することで既存のイメージをダウンロードして実行することができる コンテナとVM VM VMはハイパーバイザを通してホストOSに対してのシステムコールを解釈させるなどの必要がある それぞれのVMには全て独立したOS・アプリケーション・ライブラリが必要 コンテナ ホストのカーネルは実行されるコンテナと共有される(コンテナは常にホストと同じカーネルを
最近RubyとReact.jsをよく利用していて、Rubyで扱っている値をJSONとして表現したいケースが増えてきた。こういうのどうやっていますかと人に聞きたいので、自分はこうやっていますよというのを説明のためにまとめておくことにする。 概観 自分の場合、次のような方法で実装することが多い。 JSONとして表現したいオブジェクトをコンストラクタで受け取るクラスを定義する クラスに #as_json を定義して適当なHashを返すようにする Object#to_json が再帰的に #as_json を利用するようにする (ActiveSupportがやってくれる) コード 具体的には、以下のようなクラスをつくっている。これは最近つくっている掲示板での例で、Megaboard::Resources::Comment はコメントのJSON表現のためのクラスである。いわばコメントのJSON表現に
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか?順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
Redis を使って応答時間を半分にした話 はじめにはじめまして。 5月にFiNCに入社し、サーバーサイドの Rails エンジニアをやっている亀田と申します。 今回は、Redis を使ってチャットのパフォーマンスを改善した話について書きたいと思います。 チャットで起きていたパフォーマンス問題FiNCアプリにはチャット機能があります。ユーザー同士のコミュニケーションにも使えますし、お得情報の配信やユーザーのサポートなどでも利用しています。 その中で、ユーザーサポートの社内オペレーション用ツールに、(業務に支障が出るレベルではないものの)表示が重いという問題が発生していました。具体的には、対象となるルームのレコードを取得するために数百ミリ秒かかっており、レスポンスを返すまでに合計で1秒前後かかっているという状況でした。 分析をしてみたところ、インデックスを使って対象となるレコードを取得した後
2016 - 10 - 04 体を鍛えるなら自宅で筋トレしよう!ジムに通う必要はありませんよ! 筋トレ 習慣 ダイエット どうもニコ(
大分たってしまったけど、ようやく時間が空いたので、db tech showcase Tokyo 2016 http://enterprisezine.jp/dbonline/detail/8466 で話した内容を記録的に書いておく。あとはSILOの解説を特に自分用に論文の4章を中心に整理しておく。あとはついでに自分の思うところも記す。 ・SILO 元論文はこちら、執筆陣はMITのLiskov一派とEddie Kohler 現在のDB研究の第一線のメンバー。 http://people.csail.mit.edu/stephentu/papers/silo.pdf SILO以降、大きくDBベースのアーキテクチャの考え方は変わりました。ほとんど全ての分散系OLTPはSILOを程度の大小はあるとはいえ、意識していると言っても過言ではないでしょう。前世代ではほぼ「空想か?」ぐらいの扱いだった分散t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く