ぼくたちのかんがえたさいきょうのi18n国家
本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一瞬で滅びそう — Masaki Hara (@qnighy) 2018年8月6日 長い前置き ソフトウェアのi18nは難しい。自文化では当たり前と思っていてハードコードしてしまった仮定が崩れて、大幅な再設計を余儀なくされるからだ。気づいて再設計できればまだ良
データサイエンスプロジェクトのディレクトリ構成どうするか問題
あるいは、論文 "Best Practices for Scientific Computing" および "Good Enough Practices in Scientific Computing" について。 TL;DR 標題の件について、未だに答えは見えていないのだけど、自分の現状と他の人の例を文字で残しておく。 こういう話で「あーその手があったかー！」と知ったときの興奮はすごいので、みなさんもっとオープンにいきましょう。 大切なのは、ソフトウェア開発と同じ要領でデータサイエンスのプロジェクトを捉えて、分析と言う名の“開発”を行うつもりでディレクトリを掘ること。 必要なものリスト ナウいデータサイエンス/機械学習プロジェクトの中には（経験上、ぱっと思い浮かぶだけでも）次のようなファイル群があって、僕たちはそれらを良い感じに管理したい。 ソースコード 役割がいろいろある： 前処理（こ
コミットメント言語で大事なのはそれが制御下にあるかどうか - snoozer05's blog
拙訳『エラスティックリーダーシップ ―自己組織化チームの育て方』にコミットメント言語 (Commitment Language) というものがでてきます。コミットメント言語とは、簡単にいうと「言質を与える言い方」のことで、本書では「仕事では自分が何を行うかを言質を与える言い方で約束すべきである」という話で、このコミットメント言語というものがでてきます。 具体的にいうと、希望的な物言い（「したいと思います」「しようと思ってます」「やれると思います」）やコミットメントを表明しない言い方（「はやったほうがいいとは思っています」「やらないといけないとは思ってます」）をせず、やることを約束する言葉遣い（「〜します」）をするようにしましょうという話です。 ですが、実はここだけを切り取って読んでしまうと勿体なくて、著者のロイがコミットメント言語の章で伝えたい主旨は、単に言い方だけを変えなさいという話では
QA to AQ: Quality Assurance から Agile Quality へ - Qiita
伝統的な品質保証(QA)からアジャイル品質(AQ)へと変わっていこう 2016/9/30、Hillside Group(後述)の代表Joseph Yoderさんが来日され、鷲崎先生と特別セミナーが開催されたとのこと。 そこで紹介された、「QA to AQ: 品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ」というパターンが秀逸で、かつ、日本のアジャイルオーディエンスに興味がある方が多いであろう、と思い、紹介します。 アジャイル開発は徐々に日本の開発現場にも浸透しています。特に、Webサービスを事業としている会社、スタートアップ企業、などでは普通になる一方で、ITを利用する側と開発を請け負う会社が分かれている場合、また、組み込みの製品開発などでも、まだまだアジャイルは浸透が足りないようです。開発部隊と別に、品質保証部がある組織も、組み込みでは珍
マイクロにしすぎた結果がこれだよ！
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
リモートチームのメンバーが気をつけている常識ではありえない４つの習慣 | Social Change!
リモートチームとは、物理的に離れた場所で働きつつもチームワークを発揮して、チームで助け合って成果を出していく働きかたです。私たちソニックガーデンでは、リモートチームを５年以上続けてきました。 この記事では、私たちが経験から学んできたリモートチームを実現するときにメンバーが気をつけておくと良いだろうと思う４つの習慣について書きました。 １）仕事に関する「雑談」をして連帯感を出す習慣 チームビルディングの第１歩は、チームを構成するメンバーをお互いに仲間だと認識することから始まります。それはたとえリモートチームであっても同じことです。 もしオフィスにいれば、飲み会や食事の機会があったりして、お互いのことをなんとなく認識することが出来るのかもしれませんが、リモートではそうはいきません。 そこでリモートチームでは、互いに認識しあう機会として、あえて仕事の合間に雑談をするよう気をつけています。雑談とい
"リニューアル"っていうな - komagataのブログ
結論 リニューアルはマーケティング用語。Webサービス開発チームにとっては思考停止やストーリーの粒度アップをもたらす悪魔の言葉なので使わないようにしよう。 すぐリニューアルっていう問題 Webサービス開発においてサイト改善の粒度がリニューアルという名前になってたら要注意。 その場合、責任者が 「よくわからないけど、うちのサービスイマイチだからおれのかんがえるさいきょうの機能・UIに刷新しよう」 と考えていて、 自分のサービスにとって良いとは何なのか？ 何が問題点・ボトルネックなのか？ 何を改善するのか？ その仮説で本当に改善するのか？ そもそも仮説はあるのか？ 優先順位は？ などという地味な検討を避けてリニューアルという銀の弾丸を求めても、かさむ工数、ユーザー離れ、要らない機能などがサイトにもたらされるだけなのでヤメよう。対外的なマーケティング用語としてのリニューアルをWebサービス開発に
【前編】華麗なるキャリアの道程は、『ドワンゴ』から逃げ出したい一心から！？
Twitterでハッシュタグ「#naoya_sushi」が生まれてしまうほど、無類の寿司好きとして知られる伊藤直也氏（@naoya_ito）。そんな伊藤氏をホスト役とし、トップエンジニアをゲストに招いて、寿司をつまみつつホンネで語ってもらおうという、この企画。 第七回にして本対談もついに最終回を迎えることになりました。その栄えある最終回を飾ってくださるのは、あの『株式会社ドワンゴ』の川上量生氏！ 創業期からエンジニアとして第一線で活躍し、現在は代表取締役会長と『象徴CTO』を兼務。そして『株式会社KADOKAWA・DWANGO』（10月１日付で社名を『カドカワ株式会社』に変更予定）の代表取締役社長、『スタジオジブリ』のプロデューサー見習い、アニメーション製作会社の『株式会社カラー』では取締役と、業界では知らぬ者はいないスーパースター。そんな川上氏が、プライベートでもゲーム仲間として交流のあ
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
RescueTime
Take back controlof your time Millions of people simplify their lives by installing RescueTime's automated time tracking software.
現場のフォーム - steps to phantasien
このごろ仕事の進みが悪く、しかもまったくの自業自得で肩を落としている。 今日はそれをふりかえり明日への糧としたい。反省文。 仕事の進みは「遅い」だけ。動いてはいる。一歩一歩は正しい。 でも一歩を踏み出すまでが遅い。正しい一歩を踏み出せる、正しい姿勢をとるのが遅い。 背中を丸め足を引きずる。たとえばこんなふうに… Bisection ある昼下がりにバグ修正を頼まれた。リグレッション。ここ三ヶ月くらいで壊れたらしい。 リグレッションを直す「正しい」一歩目は、二分探索で原因のリビジョンを探す bisection 作業だ。 でもこのバグ、bisection が面倒そう。なんとなく原因の想像はつくからあたりをつけて直してしまおう・・・ ・・・半日たち、結局あたりはつかない。日が暮れてしょんぼり帰宅。 翌朝気を取り直し bisection をしたら 2 時間でリビジョンの特定がおわる。あらら。 しかも
第二新卒研修をしていた - ローファイ日記
雇用流動情報の季節ですが、いかがお過ごしでしょうか。雇用流動と間接的に関係のある記事を書きます。 標記の通り、研修をしていたのでその内容をまとめたり振り返ったりする。 思ったより長くなったぞ... 背景とか がっつりとしたWeb開発の経験は無いが、情熱があり、コミュニケーション能力など基本的な能力が高そうな、年齢の若い方が応募されたので、いわゆる「第二新卒」と言う扱いで研修を前提に採用した。で、その研修のカリキュラムを主にぼくが考えて実施していた。 といっても、今までに積み上げてきた新卒向け研修のカリキュラムやノウハウを眺めてエッセンスを抜き出すみたいな感じだった。 ペパボ新卒デザイナーとエンジニアの研修ブログ ペパボ新卒エンジニアの研修を開始している - HsbtDiary(2013-05-22) ペパボ新卒エンジニア研修 前編 | blog: takahiro okumura ペパボ新
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
雑なレビュー - ✘╹◡╹✘
背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと
20140131 万葉帰社日発表 チーム積み重ね 公開版
2014年3月の発表資料 2014年7月の資料 => http://www.slideshare.net/hiroosak/ca-36830962
JUST MAKE IT.
HOKKAIDO アイデアソン＆ハッカソン2014 セミナー 2014/01/17 Yusuke Wada a.k.a yusukebe
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cookpad_tech_kitchen_7
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について #devlove #devlove創
Ruby プロセスを追いかけるツール(プロファイラとか)10選 - sonots:blog
