JavaScript Stringでサロゲートペアを扱う - teppeis blog
JavaScriptで強力なUnicodeを扱う方法について書きます！（嘘） 先月末に発売されたWEB+DB PRESS Vol.78で「フロントエンドの国際化」の記事を書いたのは前回書いた通り。 WEB+DB PRESS Vol.78に「フロントエンドの国際化」について書いた！ - teppeis blog 記事内で、JSの文字列は基本UTF-16なのでサロゲートペアがうまく扱えないっていう問題は書いたけど、じゃあどうすればいいの？っていうのは載せられなかったので書く。 文字数のカウント 「𠮷（U+20BB7、つちよしだ）」や「𩸽（U+29E3D、ほっけ）」はUTF-16ではサロゲートペアで表現するのでlengthが見た目とズレる。 console.log("𠮷野家で𩸽".length); // 7 これを「5文字」とカウントしたいという話。 正規表現を使う方法 たぶん実装が一番
A/Bテストのガイドライン：仮説検定はいらない（Request for Comments｜ご意見求む） - 廿TT
本記事の編集方針 ※この記事に興味をもたれた方は、 A/Bテスト カテゴリーの記事一覧 - 廿TT も、必要に応じてご覧いただければと思います。 本記事はもともとは、「A/Bテストの数理」への批判：「有意」とはなにか の続き的なエントリでした。 しかし、予想外に反響があったため Request for Comments（ご意見求む）の精神で、随時更新している部分もあります。 ただし、ベースとなる主張、Web系施策のA/Bテストに、仮説検定は向かないという部分は変化していません。 もしぼくの考えが変わり、「やっぱ仮説検定、いいかも」となった場合、本記事の存在価値はほぼ消滅します。 そのようなことがあれば、ページ最上部に「考えが変わりました」と明記します。 また、他の修正箇所も区別して明記し、差分がわかるようにします。 ただし細かい言い回しや、誤字脱字等はだまって修正します。 目次： そもそも
ポイント切り替え「４秒短縮」で列車運行「１・７倍」に！ 東海道・山陽新幹線に新システム ＪＲ「効果絶大」 （1/2ページ） - MSN産経west
たかが４秒、されど４秒…。ポイントの切り替えなどを自動的に行う東海道・山陽新幹線の運転管理システム「コムトラック」が、今月１２日から新しいシステムと取り換えられる見通しとなった。６年がかりで開発した新システムでは、ターミナル駅でのポイント切り替え時間が４秒短くなる。ダイヤが大幅に乱れた場合でも列車の折り返し時間が早くなり、１日に設定できる最大列車本数も現在の１８００本から３千本に約１・７倍増える。 「たかが４秒と思われがちだが、効果は大きい」。ＪＲ東海の担当者は新システムに自信を見せる。 昭和３９年の東海道新幹線開業当時は、新幹線総合指令所（東京）の指令員がポイントの切り替えなどを行い、「人の手に頼っていた」（ＪＲ東海）。 コムトラックは、山陽新幹線新大阪－岡山間が開業した昭和４７年、初めて東海道・山陽新幹線に導入。その後も改良が重ねられ、現在のシステム（第８世代）は平成１５年に導入された
抽象化に関して「知りたいこと」を募集します - 西尾泰和のはてなダイアリー
来る1/10〜12の「第55回プログラミング・シンポジウム」にて「抽象化」をテーマとしたセッションを行います。 セッション概要 「抽象化」をキーワードに、参加者から「知りたいこと」を募集、みんなでそれに対する答えを考えてワイワイする会です。 「知りたいこと」の例 プログラムを書く上でどこまで抽象化するのか？ どうやって適当な抽象化レベルを判断する？ 抽象化する上での適切な言語の選択がある？ 抽象的に考えることをどうやったら習得できる？教えられる？ そもそも「抽象化」って何？ 抽象化のオーバーヘッドはどこまで軽減できるのか？ OSの権限分離のような強制的抽象化と、フレームワークのような強制でない抽象化について、何か違いはあるか？ 抽象化をうまくやる，あるいは抽象的に考えるには，どんな環境・制約があるといいのか？(今回「知りたいこと」という制約を付けたことが具体例。他には？環境の具体例としては
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
