[テキストマイニング] Clojureでテキストマイニングをしたい!という方がTLにいらっしゃったので、 Clojureという言語とkuromojiという形態素解析器を用いたテキストマイニング入門の記事を書きます。 この記事の通り手を動かすと、様々なテキスト、例えばアンケートの自由記述やブログ、twitterなどの文章に形態素解析を掛け、ワードカウントと呼ばれる、ある単語が何回出現しているのかを解析する手法を使えるようになります。これを利用し、出現単語を頻度順に並べてランキングを作るなどして、その文書の特徴を明らかにするなどが出来るようになります。 ある程度コンピュータを使えることは求めますが、プログラミングの前提知識はさほど求めていません。そのため、所々天下りなところ(ここはとりあえずこうやってください!と説明無しの記述)もありますが、ご容赦ください。 形態素解析とは? 形態素解析とは、
概要 社内勉強会でcookieの仕様(主にRFC6265)やセキュリティ(主にCSRFやセッション乗っ取り)について話した内容をまとめます。 但し書き 手っ取り早い説明用に内容を端折ってまとめているため、厳密には正しくない記述が含まれます。 ちゃんと知りたければRFC読みましょう。(幸い日本語訳があってかなり読みやすいのでオススメ) 以下、RFCに沿って「サーバー」と「UA」という単語を使いますが、UAはブラウザと言い換えていいと思います。 curlやプログラマブルなクライアントは、この枠外の挙動をさせることも容易なので対象外です。 またブラウザ毎の実装については、過去の他の方の記事を参照していて自分で試せてはいないため、現在では実装が異なっている可能性があります。 cookieの仕様 cookie(webでの状態管理メカニズム)についての仕様。 RFC6265 今の最新の仕様っぽい。モダ
Microservices Advent Calendar 2016 の5日目です。 11月にFiNCさんのMeetupで発表させていただいた 「Auth0を使ってサインインを一括管理したりAzure Functionsをセキュアにしたりした話」 が中々の反響だったのでAuth0について詳しく書いてみようと思います。一応クラウドサービスを利用するという点でギリギリマイクロサービスの範疇なのでは…という解釈です。 (@qsona さんの記事とは全然違う方向性で恐縮です。) Auth0公式サイト 読み方はオースゼロです。 Auth0を理解する Why Auth0 の動画を観ます。2分くらいです。今すぐ観て下さい。英語がわからなくてもOKです、紙芝居をお楽しみください。 動画を最後まで観たら次に進みましょう。 What a cool service!! なんて素晴らしいサービスなんだ!そうだ、俺
freee のCEOの佐々木大輔です。freee Advent Calendarの13日目、本日は、freeeを支えるマジ価値開発についてのお話。 freeeでは freee が重要と考える価値基準の1つとして「ユーザーにとって本質的な価値があると信じることをする(通称、マジ価値)」というものを持っている。 当然、freeeのプロダクト開発においてはマジ価値を貫かなくてはならないし、それは容易ではないチャレンジだ。 ポイントは、ユーザーにとって本質的な価値があると、「自分が」信じることをするというところにあって、ここまで考え抜くということは容易ではないし、その結果はあまりにも抜本的すぎて、その時点ではすぐには理解されないということもあるだろう。このようなマジ価値開発を実践するためのポイントをまとめてみた。 観察による課題発見がベスト 本質的な価値を提供する上では、まず顧客にとって重要な課題
こちらははてなエンジニアアドベントカレンダー 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
こんにちは、はてなシニアエンジニアの id:y_uuki です。 今年もアドベントカレンダーの季節がやってきましたね。昨年のアドベントカレンダーの記事は以下のページにまとまっています。 明日の12月1日から25日まではてなのエンジニアの誰かが毎日エントリーを書く毎に、以下にリンクを追加していきます。お楽しみに! 12月1日 developer.hatenastaff.com 12月2日 CSS の -webkit-line-clamp プロパティについて by id:nanto_vi 12月3日 developer.hatenastaff.com 12月4日 blog.yuuk.io 12月5日 developer.hatenastaff.com 12月6日 medium.com 12月7日 ichirin2501.hatenablog.com 12月8日 developer.hatena
Septeni Originalの大久保です。 世間ではSPAが流行ってるかと思います。 ただHTMLのレンダリングはサーバー側で行うケースは以前多いのではないでしょうか? 現在自分が携わってる新規プロダクトでモダンなフロントエンドの技術(WebapackやES2015など)を使いつつ、HTMLレンダリングはサーバーに委ねるようなアーキテクチャ(Multi Page Application)の調査を行ったので、そこでの知識を備忘録的にまとめたいと思います。 今回作成したコードはGithubにあげているので、興味あればご参照ください。 Github URL:https://github.com/yoppe/webpack-es2015-base-for-play #やりたいこと バックとフロントのGitリポジトリを分けずに作る。 ⇒ リリース時などにバックとフロントを別々にリリースしたりデプ
はじめに これは、システムエンジニア Advent Calendar 2016 の5日の記事です。 みなさーん、リトライ処理を書いてますか? え、書いたことすらないって。私も10数年SEをやっていて幾つものプロジェクトを経験していますが、リトライ処理を書いたのは数回程度です。 もしかしたら、ライブラリー側にリトライ処理が書かれていて意識されてないってこともありえますけどね。 その数回のリトライ処理も改善対応による後付けのもので、設計段階からリトライ処理を組み入れたことはありません。 リトライ処理とは リトライ処理は、ある処理で何らかのエラーが発生した際、処理が成功するまで無条件かリトライ回数だけ、一定秒数待機するなどしてから繰り返す。 また、エラーに特定のコードや文字列が含まれていた場合のみリトライすることもある。 リトライ処理されたらログ出力し、リトライさせた原因が分かるようにしておくと
compiled Svelte shifts as much work as possible out of the browser and into your build step. No more manual optimisations — just faster, more efficient apps. compact Write breathtakingly concise components using languages you already know — HTML, CSS and JavaScript. Oh, and your application bundles will be tiny as well. complete Built-in scoped styling, state management, motion primitives, form bi
お題「エンジニア立ち居振舞い」 僕は今のチームでフロントエンド担当ということになっている。 一応肩書は「アプリケーションエンジニア」だしサーバー側のコードもガンガン書くけど、他のエンジニアとの立ち位置を考えると自然と担当範囲が決まってくる感じだ。 担当範囲の決め方 うちの会社ではWebサービス開発を行うエンジニアを「アプリケーションエンジニア」として一律に扱っているが、その実メンバー毎になんとなく担当範囲が存在する。 担当範囲は、個人的な嗜好、経緯、あとはチーム内での分担で決まる。 僕の場合は、フロントが好きということもあったし、チームに入ってすぐフロントのタスクをゴリゴリ進めた結果、すんなり現在のポジションに落ち着いた。 チーム内で一番JS書ける必要はなくて、チーム内での比較優位で決まることもある。 今のチームでもう2年以上も働いていて、その割に知らない仕様とか沢山でてくるけど、それらを
WEBアプリケーションの前段に CDN として CloudFront を使っているとスマホ判定やhttps判定でCloudFront用の特別設定を開発者側にしてもらう必要がある。 具体的には User-Agent が取れない代わりに CloudFront-Is-Mobile-Viewer, CloudFront-Is-Tablet-Viewer, CloudFront-Is-Desktop-Viewer, CloudFront-Is-SmartTV-Viewer などを見るようにする。 また、一般敵なProxyを経由したときのhttps判定では X-Forwarded-Proto を見るところ、CloudFront では CloudFront-Forwarded-Proto というヘッダを見てやる必要がある。 で、多くのアプリでは User-Agent 判定に iPhone/iPad など
GoogleAppEngineの勉強中です。 3回に分けて、GAEで日本語の形態素解析を試してみたことを書いています。 第1回 lucene-gosenを使ってみる 第2回 lucene-gosenのTokenFilterを試す 第3回 Kuromojiを使ってみる 今回は、第3回です。 使っている環境 Java JDK1.6.0_35(64bit版) Google App Engine SDK for Java 1.7.1 Eclipse IDE for Java EE Developers_ Juno (4.2)64Bit版 The Google Plugin for Eclipse, for Eclipse 3.8/4.2 (Juno) kuromoji-0.7.7 (1)はじめに もともと、kuromoji に関しては、GoogleAppEngineで動かせないと思っていました。
brevis.exblog.jp を読んだ。 要約すると、「業務改善には一時的にコストがかかるけど、そこは頑張ってやらないとジリ貧になるよ」ということなのだが、末端のフリーランスIT土方の立場から言わせてもらうと「知らねーよ」という感想しかない。 まあそれだと話が終わってしまうので、私がサラリーマンで、末端の平社員IT土方だと仮定して、ボトムアップ型の業務改善が成立する条件を考えてみたい。 カイゼンする空気を作るということ カイゼンと言えばトヨタであり、トヨタといえばカイゼンだが、噂によるとトヨタの工員たちは、頼まれもしないのにガンガン作業をカイゼンさせて勝手に作業効率を上げていき、いよいよ自分の工程がカイゼンできないまでに最適化されてしまうと、ロボットに置き換えられ、今度は自動化されていないラインに移動させられ、再び自工程を一からカイゼンできることに涙を流して喜んでしまうほど「カイゼン空
はじめに こちらのエントリはソフトウェアテストAdvend Calendar2016の13日目の記事です。 qiita.com ちなみに、昨日のエントリ、テスターがエンジニアとキャッキャウフフしながら文言指摘軽減を技術的に30分で解消したかもしれない話 - テストする人。は、キャッキャウフフしてる感じが楽しそうですね。 DevOps時代のテスト要求分析は難しい DevOps時代のテスト要求分析は難しい。それは、ウォーターフォール時代のテストで基本として使われていたVモデルによる従来のテスト戦略をそのまま適用することが出来ないからだ。これにはいくつかの理由がある。 (理由1)ビジネスの成熟度によってサービスやプロダクトに重要な品質が変化する (理由2)開発中にシステムのアーキテクチャ設計が変化する このブログエントリーでは、これらの理由を解説したのちDevOps時代のテスト要求分析の方向性に
JPAの新しいメンバーのもと、REBOOTされたYAPC::Asia、YAPC::Hokkaido 2016 SAPPOROに、ゲストスピーカーとして呼んでいただけたので、行ってきました。 発表資料はこちら。 メルカリの技術ブログで紹介したSRE、1年たってエンジニアの新しいロールとして少しずつ浸透してきたと思います。今回の発表ではSREとはということで、本家であるGoogleのSREについて、メルカリでの取り組みについて、そしてYAPCなので、SREとPerlを結びつけてまとめとしました。参考になれば幸いです。 今回のYAPC、試させる大地での開催、それも29年ぶりの大雪という悪天候に見舞われましたが、普段なかなかない環境ということでかなり楽しめました。 1日目 まず飛行機が30分遅れ。途中で引き返すかもよという条件付き飛行で出発 11:00 発が 11:25 発になったぞ。。— mas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く