海外進出を成功させる為に必要な3つのポイント デザイン会社 ビートラックス: ブログ
日本の方々にお会いする際に頻繁に話題に上がるのが、「海外展開を成功させる為の秘訣」である。つい先日、日本から来られたメディアの方からのインタビュー時に余談として尋ねられたり、約2週間程前に日本出張へ行った際に多くの方に聞かれたりもした。 その度に自分でも真剣に考えるようになり、それなりの結論が出たので、まとめておく事にした。 日本の企業が海外展開を成功させる為には、実に数多くのハードルを乗り越えなければならない。しかしながら、よくよく考えてみると成功のカギは最終的には下記の3つのポイントに集約されるのではないかと思われる。 ポイント1: プロダクトの品質一つ目は単純明快、商品やサービスのクオリティである。やはり、海外展開の第一歩は、日本国内だけではなく海外の消費者に使ってもらえて、喜んでもらえるプロダクトを提供する事から始まる。 ただ、一口に「品質が良い」と言っても漠然としすぎているので、
海外でWebサービスを展開するときに知っておきたい税金のこと - Qiita
この記事は2016年時点の調査内容を記載したもので、既に制度が変更されています。 変更の詳細はこちらをご参照ください。 European Commission公式 : The VAT e-commerce package and the MOSS / What changes on 1 January 2019? 解説記事: EU VAT threshold on digital goods changes in January 2019 グッドパッチでサーバーサイドエンジニアをしている、やっはーです。 今日はProttで実装した、Webサービスでの海外課税に対して、１エンジニアとしてどう越境していったかという話です。 「グッドパッチなのにデザインの話じゃないんかーい」というツッコミが聞こえてきますが、「ハートを揺さぶるデザインで世界を前進させる！」をビジョンに掲げているグッドパッチなので
就活生よ、偉そうになれ！ Ruby開発者まつもとゆきひろ氏がエンジニア志望学生に贈る言葉 - ZOZO TECH BLOG
こんにちは、VASILYバックエンドエンジニアの塩崎です。 今年の就職活動のスタートは3月になるそうなので、学生の皆さんは自分の進路について色々と悩んでいる時期かと思います。 今回のTECH BLOGは、Rubyの開発者であり、VASILYの技術顧問でもある、まつもとゆきひろ氏（以下、Matzさん）にエンジニアの就職活動について色々と質問した内容をお届けします。 将来エンジニアとして活躍したい学生さんの助けになればと思います。 Matzさんが学生の頃のインターン ― Matzさんが学生の頃のエンジニアの就活は今と比べてどうでしたか？今のようなインターンは当時からあったんでしょうか？ インターン自体は当時からあったんですが、今のように就職に直結するものではありませんでしたね。社会経験みたいな形でインターンに行きました。内定が目的のインターンではなく、バイト感覚でした。 ― 今のインターンは内
「バックログに入らないタスクを可視化する仕組み」という話を技術勉強会でしました - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:daiksy です。 はてなでは毎週木曜日に技術勉強会を開催しています。 参考: 寿司と勉強会とエンジニア - Hatena Developer Blog 先週、当番が回ってきたので、「バックログに入らないタスクを可視化する仕組み」というトークをしました。 speakerdeck.com 詳細はスライドを見ていただくとして、この発表で定義された「税」などの用語が、さっそく社内でのコミュニケーションでも使われだして、エンジニア同士で、ある概念について共通の認識を持つためにもこういった場は効果があるな、と実感しました。 はてなでは、アプリケーションを構築する技術だけではなく、プロジェクトマネジメントやチームビルディングの知見などもこうして技術勉強会で共有されています。
DB論理設計のノウハウ - Qiita
DB設計の概要を簡単におさらいした後、論理設計について主にまとめていきます。 DB設計の全体手順のおさらい DB設計は、大きく論理設計と物理設計に分けられます。 概念スキーマを定義します。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 物理設計 論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決めます。 テーブル定義 インデックス定義 ハードウェアのサイジング ストレージの冗長構成決定 ファイルの物理配置決定 テーブルの構成要素のおさらい 行と列 行(レコード)：横のデータの組 列(カラム)：縦のデータの組 キー キーとは、DBのテーブルから特定のデータを引き出すための鍵です。 主キー：その値を指定すれば、必ず一行のレコードを特定できるような列の組み合わせのこと。一意にレコードを識別するためにある 外部キー：2つのデーブル間の列同士で設定するもの。参照
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
Clojureの作者が作ったデータベースDatomicが凄い
プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ本番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ
変更履歴を持つテーブルの設計 - Qiita
ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
