Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話 - いくやの斬鉄日記
オープンソースからハイスクールフリート、The Beatlesまで何でもありの自称エンターテインメント日記。 最近TransifexとかLaunchpad (のRosetta)とかPootleなどなどを採用し、オープンソースソフトウェア(OSS/FLOSS)の翻訳がWebでできるようになっています。 同時にWebの翻訳サービスも多数存在し、どんどん精度が上がってきています。 ではWeb翻訳の結果をOSS翻訳に突っ込めばいいのではないかというと、それは違います。Web翻訳にも当然利用規約があり、そのようなことは禁止されてることが多いです。世の中すべてのサービスのライセンスを確認するのは不可能ですが、概ねその傾向にあるのは事実でしょう。具体的にはExcite翻訳の利用規約だと第6条で明記されています。 OSSの翻訳にするということは、そのOSSのライセンスに従うということで、それは > 私的利
第3回 ブランチvs.フラグ | gihyo.jp
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
devops - Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita
Feature Toggles Pete HodgsonさんというThoughtWorksの方が書かれたFeature Togglesという記事が面白かったので翻訳してみました。 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016の記事で取り上げていただいた通り、マイクロソフトの内部の開発では多くのフィーチャートグルが使われています。このことをより深く理解したいと思って個人的に翻訳したものを公開します。私的な自分が理解する用の翻訳でありますので、その辺はご考慮いただければと思います。Pull Requestは歓迎いたします！ 概要 フィーチャートグルズ(Feature Toggles)は、とてもパワフルなテクニックだ。チームがコードを変更することな
イギリス政府の大変革はGitHubが引き金だった？ 巨大組織が「実験する自由」を手にできたワケ | CAREER HACK
イギリス｜専門機関におけるGitHub活用事例 ※サンフランシスコにて2016年9月に開催された「GitHub Universe 2016」よりレポート記事をお届けします。 GDS（UK Government Digital Service）は、エンジニアやデザイナー、アナリストなどさまざまな専門家によって編成されている機関だ。現在、このGDSが主導し、イギリス政府内に大きな変革が起こっているという。 GDSが設立されたのは、2010年のこと。その背景には、当時のイギリス政府のポータルサイトが、あまりにも使いにくいものだったいう問題がある。 「当時、イギリス政府のポータルサイトには数え切れないほどのリンクが貼られていました。だから、ユーザーはどこを見ていいのかわからず混乱してしまったのです。実際、政府内部の人間さえ混乱していたのです。一般市民が混乱しないはずがありません。使用しているソフト
ディープワークの本 - hitode909の日記
ディープワークは邪魔されず集中して取り組めて，価値あることを成し遂げるような仕事，シャローワークは，メールに返信したりとか，事務作業みたいな仕事．ディープワークが大事，という本． 邪魔されないようなライフスタイルの組み立て方も載っていて，「インターネットしない日を作る」ではなく，「インターネットする時間を決める」とか，けっこうストイック．SNSを使うべきかどうかという議論も載っていて，目標を直接支援しないならやめましょう，ということだった．クヌース先生はメールを使わないことで，ディープワークに集中できている． クヌースにツイッターのフォロワーをつくることや、もっと自由なメールのやりとりで生まれるかもしれない予想外の好機を売り込んでも無駄だろう。これらは直接、彼の目的の助けとはならないからだ。 ソフトウェア作ってるチームでチーム歴が長くて便利な人になっていくと，Slackで絶えず話し続けて，
Deep Work を読んだ - 大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法 - higepon blog
omo さんがおすすめしていた Deep Work を熟読した。Deep Work とは「長期間中断しない難しい知的作業」のこと。その Deep Work がいかに大事か。そしてもっと時間を費やすべきかという内容。Deep Work と対極にあるのが Shallow Work。Twitter/Facebook/Instagram で過ごす時間、メールをチェックする時間など。Deep Work を邪魔するもの。 内容は耳が痛いものばかり。自分がどれだけ「Twitter に時間を費やすこと」を正当化していたかよくわかった。自分でも気づいているものばかりで、当たり前に思える内容だが、他人に指摘されると自分の甘さがよく分かる内容だった。少しずつ Shallow Work を減らしていきたいと思う。 描いたマインドマップ
t_wada さんを囲んだ - おいちゃんと呼ばれています
今日はペパボの社内勉強会に TDD の実践者として知られる @t_wada さんが来てくださって「毎日コードを書く」ということについてお話をしていただいた。内容はおよそ こちら にあるようなことで、お話いただいた後の質疑応答でも、大変参考になる知見が得られたので、感謝の気持ちを込めてメモ。 何を得ようと思って参加したか 「今度 t_wada さんを囲む会をやるよ、内容はこんな感じだよ、希望者はぜひ参加して〜」という感じのアナウンスがされていて。 僕は以前、下記に書いたように、毎日コードを書くというのを試みたことがあって、もちろん得るものもあったが、インプットの量が減ってしまったという反省点のほうが大きかった。 プライベートで 689日連続でコードを書いた（ことの振り返り） 2016年になって、Pivotal Tracker でインプットの質と量を保てた一年だった と振り返ることができるほど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デブサミ2017、講演関連資料まとめ
GitHub - pragdave/quixir: Property-based testing for Elixir