Google Docsのスプレッドシートで多言語対訳表が簡単に作れるよ - 太陽がまぶしかったから
対訳表を作るのが面倒 システム設計をする時に、データベース名や変数名や表示名などを決めるのが面倒だ。一般的には英字文字列で作るのだけど、ローマ字で「kokyaku」とか付けるのはダサいし、いちいち辞書を引いていくのは億劫。 多言語対応のために表示名をフランス語にするみたいな要件もでてくるが、これらの作業の下準備を実現する手段として、Google Docsのスプレッドシート（表計算ソフト）の翻訳関数を利用する方法が考えられる。 =IF($A2<>"", GOOGLETRANSLATE($A2,"ja","en"),"") 指定セルの内容を翻訳するには「GOOGLETRANSLATE(値,ソース言語,ターゲット言語)」関数を入力する。例えばセルの計算式に上記式を入力すると「A2セルの内容がある場合にA2セルの値を日本語から英語に翻訳する」という意味になる。 スプレッドシートで多言語対訳表を作る
現場ロックインが技術力さげてるのかもしれない - Javaプログラマのはしくれダイアリー
はじめに 技術を学ぶというのはすごい個人差のあることだと思います。 個人特性もあるし、興味の向く対象も違う。 組織にはいろんな人間がいる。 そんな中、いくら「技術力を学ぼう！」と啓蒙しても、 響かないことってありませんか。 最終的には人それぞれの問題にはなってくるのだけれど、 それって、現場ロックインが一因なのではないかなと思う。 現場ロックインの定義 「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。 (Wikipediaより引用) 現場ロックインは僕の思いついた単なる造語で、 「特定のプロジェクトに特化した技術や顧客の事情を重視しており、 その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。 会社に対して
○○したら受託開発が180°変わった(10分版)
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
なぜ糞システムができあがるか
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
