私は2004年、26歳の時にワーキングホリデーで、 オーストラリアへ行き英語が話せるようになりました。 そこで気づいたのですが、 ネイティブスピーカーは私たちが勉強するような、 長い英文を使っていないということです。 ほとんどが3単語もしくは4単語位の 短いフレーズを使っているのです。 中学英語の教科書のように、 小難しい文法から覚えようとすると、 英語で話すのはとても難しくなってしまいますが、 短い簡単なフレーズを覚えてしまえば 相手の言っている事がわかるようになり、 自分の意思も伝えられるようになるので 飛躍的に英語力がアップしていきます。 そこで今回は、コピペでスグに使える 利用頻度の高いフレーズを65個選びました。 ぜひ参考にしていただければと思います。 001 . Hello! やぁ！ 友人などに会ったときの第一声です。 002 . How ar

当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー『AWS サービス別 再入門アドベントカレンダー 2015』の5日目のエントリです。 昨日4日目のエントリはしんやの『Amazon Redshift 』でした。 このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 本日5日目のテーマは『Amazon Key Management Service』です。 Amazon KMSとは Amazon Key Management Service(AWS KMS)はデータの暗号化に使用する暗号化キーを簡単に作成および管理できるマネージドサービスです。 以下のような特徴があります

ブックマークをタグで分類タグを使うと、ブックマークを分類することができます。タグとは、カテゴリあるいはフォルダのような、ブックマークを分類するための自分だけの識別子です。 ブックマークにタグをつけるには、コメントの先頭部分にタグを記入します。先頭から [...] でかこった単語がタグになります。例えば、『 [hatena][news] 』 と記述すると「hatena」タグと「news」タグを付けたことになります。 また、コメント欄下部の「タグを追加する」につけたいタグの名前を入力することで、同様の表示が可能になります。 「おすすめタグ」には他のユーザーがよく使っているタグが、「よく使うタグ」には自分がよく使っているタグが表示されています。これらをクリックすることで、直接タグを付けられます。 ブックマークにタグを付けておくと、同じタグを付けているエントリーをまとめて見られるようになります。は

さった1月16日の「パリ白熱教室」は、労働所得格差がテーマでした。 NHK パリ白熱教室 最初に、トマ・ピケティ教授が講義で説明した3つの表を紹介します。（注：日本も欧米と同じ傾向にある、ということです。） (1) 時代と国別に見た労働所得格差 低格差 1970〜80年代 スカンジナビア 中格差 2010年 ヨーロッパ 高格差 2010年 アメリカ 超高格差 2030年? アメリカ? 上位層(10%) 20% 25% 35% 45% 最上位1% 5% 7% 12% 17% 上位層のうち 残り9% 15% 18% 23% 28% 中位層(40%) 45% 45% 40% 35% 下位層(50%) 35% 30% 25% 20% ポイントは、最上位1%層の労働所得です。人間が仕事で産み出す価値（お金）がここまで開くのは過去には例がないのではないでしょうか。また中位層と下位層が近づくということは

東京で最も住みにくい街ランキングがヤバすぎるｗｗｗ【台湾人の反応】 5位：亀有駅〜綾瀬駅付近（足立区） 「これといった繁華街が無いのに犯罪が多く起きるなど、とにかく治安が良くないですね。年々数は減っている とはいえ、犯罪発生件数はまだまだ多いです。特に女性が一人で住むのはあんまりおススメできないですね」 4位：吉祥寺（武蔵野市） 「家賃高い、そんなに交通の便よくない、なのに治安もたいしてよくないという不思議な街なのに、なぜか住みたい街に 毎回ランク入りする謎の市です。多分吉祥寺に1回でも住んだことがある人にまた住みたいか聞いたら、答えはNOという 人が多いと思いますよ」 3位：お台場周辺の臨海地区（港区〜江東区） 「災害時に橋が通行止めになったら、自家用ヘリでも無い限りどこにも逃げられなくなったり、駅前からちょっと離れると 倉庫や空き地だらけという超絶不便な街なのになぜかイメージだけは良い

質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に

「オープンソースソフトウェア(OSS)」と聞いて、あなたがイメージするものはなんですか？　多くの人は Linux や Apache、Firefox といった成功した大規模なソフトウェア製品を思い浮かべることでしょう。 実は、ウェブ上でサービスを提供する会社のエンジニアたちは、これらとは別の種類のOSSを使って仕事をしています。このブログエントリでは、そのようなOSSを紹介し、それらがなぜ開発され使われているかを説明したいと思います。 ■ウェブ企業におけるOSS開発の実例と合理性 下の図は、Perl で記述される大規模ウェブアプリケーションの一般的な構成を示しています注1。このうち、「自社ロジック」と書かれているところ以外は、全てオープンソースとして開発／公開されているモジュール（ソフトウェア部品）です。各社のエンジニアが密接に協力しながら、ミドルウェアをオープンソースとして整備していること

『良いWebサービスのアイデアを思いついた！』 『でも、そのサービスを具現化してくれるエンジニアがいなくて困っている…』 ときどき、こんな話を聞きます。 でも、エンジニアを探す前にあなたがやるべきことはたくさんあります。 今日は、プログラミングができない人がアイデアを思いついた時、それをどうやって具現化していくかについてお話します。 アイデアからコードを書き始めるまでには、やるべきことがたくさんある。 エンジニアがあなたのアイデアを聞いて、『じゃ、コード書いてみるよ』というのは通常有り得ません。 なぜなら、実際に実装する(コードを書く)前には、そのアイデアがどのようなサービスで、誰が使い、どういうことができれば良いのかを決める『サービス設計』を必ず行うからです。 設計なしにいきなり実装に着手するというのは、アイデア起案者と実装者が同じで明確に頭の中で設計ができている場合か、余程単純な仕様で

数年前、三菱電機から依頼を受けて、「e-F@ctory」という同社のWebサイトに、BOM（部品表）に関する文章を書いた。今はそのurlはリンク切れになっており、同社のサイトを検索しても見つからない。サイトのリフォームにともない、この種の一般解説的文章は削除されたのだろう。そこで、当時の文章を、一部ブラッシュアップして、ここに再掲することにする。内容的に、とくに古くなってしまった部分も見あたらないと思う。製造業におけるBOM（部品表）の構築と改善は、いつでも古くて新しい課題なのである。なお、ここでは分量の関係で2回に分けて掲載する。 ＜今、なぜＢＯＭが問題なのか＞ 不況の長いトンネルを抜けて、いま日本の製造業は元気を取り戻しつつある。そして多くの企業で、この機会に生産全体のあり方を見直したい、という気運が高まっているようだ。 製造業とは、物品（マテリアル）を産出・加工し、付加価値をつけて販

就職（リクナビ）や結婚（ゼクシィ）、住宅購入（SUUMO）などの「ライフイベント領域」や、グルメ（ホットペッパー）に旅行（じゃらん）などの「ライフスタイル領域」。様々な事業領域において、情報誌やWebサービスを展開するリクルートグループ。 筆者の河野彰博氏が所属するリクルートテクノロジーズは、これらWebサービスを開発するIT機能と、グループ横断でネットマーケティングを支援する機能を担っている。 同社は事業会社におけるIT部門として、「ただ言われた通りにシステムを作る」ということは求められていない。むしろ、ITの観点からビジネスサイドに「もの申す」ことが日々求められている。 リクルートグループに限らず、ITエンジニアたるもの、これからはビジネスにもの申すスタンスが必要になる。そんな思いを河野氏はどんなシーンで発揮してきたのか。それぞれのシーンで得られた教訓とともに、紹介していく。

This copy is for your personal, non-commercial use only. Distribution and use of this material are governed by our Subscriber Agreement and by copyright law. For non-personal use or to order multiple copies, please contact Dow Jones Reprints at 1-800-843-0008 or visit www.djreprints.com. http://jp.wsj.com/article/SB10001424052702304856504579149250698533242.html

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation] Purpose Are you ready to start developing great Windows Store apps for Windows 8.1 and Windows Phone 8.1, but you don't have a PC handy? That's okay — you can use your Mac! Use popular third-party solutions like Apple Boot Camp, Oracle V

原文(投稿日：2011/11/07)へのリンク 最近、MongoDB に関して非常に好ましくない内容のかなり話題になった市場報告が２つあった。批判の大部分は、パフォーマンス問題とデータ損失の組合せに集中している。この話を続ける前に、これらは公式の事例研究でないことを肝に命じて欲しい。そうではなくて、最近 MongoDBを使った開発チームによる市場報告である。 まず Urban Airshipの Michael Schurter氏のレポートから始める。 Urban Airshipは既に、MongoDBの問題を経験しており、このレポートを書く前にデータのほとんどを PostgreSQLに移行を済ませていた。残ったデータはMongoDBにとって理想的のようだ。 短命－もしそれを失っても、短い間サービス低下を経験するが、 壊滅的ではない 小さい－容易にメモリーに収まる(~15 GB) 二次索引－キ

究極をあらわす文字"z"を冠するzsh。このシェルの力を借りて、エンジニアの日々の作業を何処まで効率化できるか、究極のシェルの最強の設定を探ります。