パーサコンビネータ を作っていたとき, 最近流行りの (?) 絵文字が変数名として使えるような言語を作る場合に, 正しくコード中の扱うにはどうしたら良いかなどを考えていたら, Unicode と JavaScript の文字列に関する理解が得られたので, ここに共有します. とはいえ, JavaScript の文字列がどう表現され, どう扱われるのかについてが主で, それ以外, 例えば正規化については紹介すらできていませんのでご了承ください (気が向いたら追記するかも). Unicode について JavaScript の文字列について説明する前に, ざっくり Unicode の仕組みや用語を抑えておきます. Unicode は文字集合 (character set) や, 以下に挙げるような符号化方式などを定義した文字コードの規格 文字集合中の文字は符号位置 (code point) と

こちらははてなエンジニアアドベントカレンダー 2016の11日目の記事です。 developer.hatenastaff.com 前日は id:Windymelt さんの「趣味のプログラミングから職業としてのプログラミングへ」でした。 windymelt.hatenablog.com 今回はAWSサービスをいくつか触ってみた話について書きたいと思います。 やったこと EC2 インスタンスの作成 VPC VPCの作成 サブネット サブネットの作成 インターネットゲートウェイ インターネットゲートウェイの作成 ルートテーブル ルートテーブルの作成 IAMロール セキュリティグループ セキュリティグループの作成 RDS RDSの作成 ALB ALBの作成 ターゲットグループ ターゲットグループの作成 ヘルスチェック ALB vs. ELB, CLB NAT Gateway NAT Gateway

この記事は、Pepabo Managers Advent Calendar 2016の3日目の記事です。2日目は、弊社チーフエンジニアhsbtさんの「マネージャが仕事の仕組みを作る」でした。 僕自身は、エンジニア専門職の主席研究員兼シニア・プリンシパルエンジニアではありますが、特にペパボ福岡のエンジニア組織を現場でまとめる人間として、エンジニア組織を成長させる中で個々のエンジニアの成長をサポートしているという意味では、マネージメントに関する活動も兼ねております。 しばしば、インターネットサービスの高度化と複雑化の速度が早過ぎるため、グランドデザインができない、人が多過ぎても成立しない、少な過ぎても難しい、とういうような類のサービスを作り上げないといけない状況があります。その際に、厳密過ぎない役割を持たせ、それぞれが横断的にそれぞれのスタイルで、まるで、攻殻機動隊の世界におけるスタンドプレー

プログラミングでよく使う英単語のまとめ【随時更新】 随時追加、整理していきます。 名前をつけるときには、名詞、動詞の違い、複数形、過去形などに注意しましょう。 オブジェクト指向では、クラス名は名詞、メソッドは動詞とします。 使ってはいけない言葉 get / set アクセサ (getter / setter) やプロパティによく使われている。 それ以外に使うと混乱を招くのでよくない。 get は軽量な処理と考えるので、中に重い処理は書いてはいけない。 単純な取得/設定以外で使いたくなったら他の言葉を考える。 load, save, commit, store, enable, disable, fetch, register, configure, add, etc... check 意味が広すぎて何をしているかわからない。 できるだけ別の言葉を使う。 具体的に何をしているかに分解して考え

麻豆影视文化传媒app下载tⅴ 官网进入,麻豆影视文化传媒官网进入,麻豆影视下载,麻豆影院是一款电影资讯手机APP，提供ios苹果下载/安卓下载。片源丰富，高潮迭起！

Spring Cloud Sleuthと、Twitterがオープンソース化したZipkinを通し、Javaアプリケーションでは分散トレーシングをどうやって行えるかご紹介します。

なんか、このサイトBootstrapくさい。そう感じることはありませんか? その理由はズバリ、欧文ベースでつくられたフレームワークを文字構造の違う日本語で適用した際に不都合が出てしまっているからです。 それらが醸し出す違和感を放っておくと、Bootstrapくささを生み出す大きな原因になってしまいます。 そもそもの問題として、欧文と比較して和文は文字の要素が多く、文字自体のリズムも少ないため、どうしても複雑で単調に見えてしまいます。 しかし、和文だからといってあきらめることはありません。BootstrapのCSSを少しだけ変えるだけでグッと見た目がよくなる隠し味をご紹介します。 1. line-heightで行間にゆとりを。明朝やゴシックなど、フォントの種類が言葉の印象を表すように、文字の行間は読みやすさ、文章全体の雰囲気を左右します。 欧文をベースに設計されたBootstrapをそのまま

ちょっと、簡単に答えられなかったので、休み中にまとめました。 「どこまで勉強すれば良いか？」 という質問には、 自分の立ち位置や、今後の目標など関わるので、 それらを踏まえて考える必要があると思います。 職種によっても違いますが、質問された時の状況は、 Web系エンジニアが新卒の子に聞かれた形なので、 考慮いただきたいです。 また、そもそも、どんな背景をもったやつが書いてるんだ？と思う方も いらっしゃるかと思いましたので、簡単に自己紹介してから書きます。 書いている人の自己紹介 現在33歳で、エンジニアスタートしたのが、 2005年08月だったので、エンジニア歴は11年となります。 ほとんどの現場がデスマーチ状態だったので、2ヶ月くらい前に転職して、 現在はホワイトな会社のリクルート住まいカンパニーで、PHPを書いています。 言語歴としては、最初にJP1スクリプトを１年半くらいやって、次に

English Grammar in Use この本はもう色んなところで紹介されている名書だ。 しかし日本ではまだ知らない人も多いと思うので、改めて紹介してみる。本当に実践的でオススメできる良書である。 世界中の英語を勉強する人達に圧倒的に支持されている参考書。 それが「English Grammer in Use」。 English Grammar in Use Book with Answers and Interactive eBook: Self-Study Reference and Practice Book for Intermediate Learners of English 著者：Raymond Murphy 「なんだ文法書か、それも洋書！」 もうこの地点でダメだと思った人もいるかもしれない。でも、ちょっと待ってほしい。なぜこの本が英語習得に必要なのかを説明するので、と

Tweet Pocket ラスベガスに行ったときに、空が雲で一面を覆われていてIt’s cloudyと思っていたら、機内アナウンスでovercastと表現されていてびっくりしました。overcastは、cloudyよりも、もっとどんよりとした雲一面の空を表すときに使うのだそうです。 確かに、曇りはcloudyで良いのですが、overcastも知っていた方が良いと思いませんか？ 実際日本の夏だってhot だけじゃ物足りないですよね。「Today is a muggy day！」「ジメジメして暑いよ」とか「Today is a schorching day！」「焼けつくような暑いよ」などと表現できたらカッコイイし、より親切な伝え方になります。 この記事では、天気を表現する英語の32個の形容詞を写真つきでまとめました。 32個もあるなんて驚きですよね。でも怖がることなかれ！イメージでインプットで

日本人は英語が話せない。 中学、高校で最低６年は英語というものを習っているのに、アジアでも最低レベルだ。 日本人は、日本人にあった英語の勉強をするべきである。 弱点をしっかり認識した上で長所を伸ばしていけば、日本人の英語も伸びていく。 この記事では、まず日本人の英語を分析して問題点を洗い出し、それぞれの問題点をどのように克服するかを具体的に説明する。そして対策として必要な教材も明確に指定する。 海外で実感する「使えない」英語 まず少し自分の経験を書いてみる。 僕は29歳にして海外移住した。そして例にもれず、日本人英語の壁にぶつかった。当時のぼくの英語力はTOEIC650程度。良くもないが悪い方ではないだろう。 現地の語学学校では中の上クラスで、語彙力・文法テストはいつもTOP3内だった。TOP3全員日本人ということもザラだった。 しかし、いざ授業がはじまり会話、ディスカッションとなると僕を

はじめに 先日、とある知りあいのRubyプログラマからこんな相談を受けました。（内容はちょっとボカしてます） 社内のコードレビューでもっときれいなコードを書けるようになった方がいい、と言われました。 「きれいなコードを書けるようになれ」と言われても、具体的にどうすればいいかわかりません。 伊藤さんのアドバイスを聞きたいです。 この内容だけだとどんな問題があるのかわからないので、実際に指摘を受けたRailsアプリのコードを見せてもらいましたが、確かに「もうちょっと頑張りましょう」と思うような点がチラホラありました。 ただ、具体的にどうすればいいの、という答えは一言では言えません。 というわけで、今回のエントリではこの悩みを解決するのに参考になりそうな話をあれこれ書いてみようと思います。 （その前に）もくじ かなり長い記事になってしまったので、先に目次を載せておきます。 はじめに （その前に）

弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊社特有の部分は一部省いています。） ああ、なんという長い旅だったろう。この会社で５年間もセキュリティを担当していたよ（諸々の失敗は許してくれ） 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、

あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

A interactive Git visualization tool to educate and challenge!

日進月歩のIT業界。毎日のように新たなニュースが飛び交い、トレンドも変わっていく動きの速い業界です。現れては消える最新技術を完璧にフォローし続けるのは不可能ですし、その必要もないかもしれません。しかし、メインストリームになったときにまったく何も知らないというのも考えものでしょう。 業界の最先端ではどんなことが起きているのか、どんな方向に向かっているのか、ざっくりと把握しているだけでもキャッチアップのスピードが変わります。IT関連のトレンドは海外発のことが多いため、先端技術の情報を収集するには英語圏のブログやメディアをチェックするのが一番です。今回は、世界の最新情報をキャッチするのにおすすめの海外ブログやメディアをまとめてご紹介します。 The Toptal Engineering Blog 出典：http://www.toptal.com/blog 世界のTOP3%に入るフリーエンジニア、

現在の仕事がひたすら海外系であるため、英語で商談できるようになるべく、 今年に入ってからガリガリとトレーニングをしております。 結果、始めて数ヶ月で英語のみで商談するにはあまり支障が無いような状況になりました。 現在は週１〜２程度で英語のみの商談が入りますが、多少効率は落ちるものの前身するには十分な状態かと思います。 ここに至るに必要だったものは何か？ 元々は大学の受験勉強で最低限の基礎知識があったことと、大学時にTOEICの受験をして850点程度だった（確か）ので、その程度ぐらいの人の事例として参考に書きます。 元々結構英語できるじゃん！と思われそうですが、肌感としては受験英語をやっていた人であれば商談するための基礎知識としてはそう大差は無いので、汎用的な内容かと思っています。 ずばり、やったことは一つだけ。 「毎日DMM英会話を２５分ずつやること」 です。 ※DMM英会話のステマ記事で

jQuery系ライブラリによるDOM操作が中心のプロジェクトにがっつり機能を追加する機会があった。 そのJavaScriptのコードは他の人から引き継いだコードで、一応引き継ぎ時にディレクトリ構成、設計、実装方針について共有を受けたが、それでもいざ手を入れようとすると自分自身のコードの理解が進んでおらず「えーっと...」となってしまった。 上記以外にも、長年、多くの人が触れてきたJavaScriptのコードに機能を追加する、修正するのはなかなか難しいのではないか、と思う。最初は、ちょっとしたユーザビリティの向上のために書かれたスクリプトが、気がつけば多数のDOM操作、至る所で宣言される変数、どこから実行されるか分からない関数群で無秩序に膨れ上がり、頭を抱えることになる(そうならないようにするのがウェブフロントエンジニアがいるひとつの理由ですが…)。 これらのケースでは、まずは修正、あるいは

コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの

「Learn Git Branching」はGitの使い方をアニメーション付きで学べるサイトです。Gitを使い始めて間もない方には重宝するサイトだと思われます。Gitでいまどういったフローになっているかを視覚的に分かりやすく解説してくれます。ブラウザがあればいつでも学習できる点も助かりますね。 以下に使ってみた様子を載せておきます。まずLearn Git Branchingへアクセスしましょう。いくつかの学習項目が用意されていますので気になったものを選んで学習できますよ。 自分でコマンドを打って動作確認できます。間違えても大きな失敗にはなりませんので、安心して気軽に取り組めますね。Gitを学習し始めた方はもちろんのこと、そろそろ復習しておきたいなという方もおすすめできるサイトです。ぜひご活用ください。 Learn Git Branching （カメきち）