文字列アルゴリズムの学びかた - Hatena Developer Blog
こんにちは！はてなアプリケーションエンジニアの id:takuya-a です。 みなさんは、このような疑問をもったことはありませんか？ grep はどのように文字列を検索しているのか？ MeCab はどうやって辞書を高速にルックアップしているのか？ パーサやコンパイラを作りたいけど、何から始めればいいのか？ 本稿では、「文字列アルゴリズムとはどんなものなのか？」「なぜ重要なのか？」「何を知っておくべきか？」「どうやって勉強すればいいのか？」といった疑問にお答えしていこうと思います。 文字列アルゴリズムの意外な応用や、モチベーションを保ちやすい勉強のしかた、文字列アルゴリズムを勉強するために行った社内での取り組み、実装するときのコツといったトピックについても触れています。 このエントリは、はてなエンジニアアドベントカレンダー2016の22日目の記事です。昨日は id:syou6162 さんに
370 Free Online Programming & Computer Science Courses You Can Start This Month
Five years ago, universities like MIT and Stanford first opened up free online courses to the public. Today, more than 700 schools around the world have created thousands of free online courses. Here are 250 Ivy League courses you can take online right now for free 250 MOOCs from Brown, Columbia, Cornell, Dartmouth, Harvard, Penn, Princeton, and Yale. Some of the most popular courses have been tho
ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊社特有の部分は一部省いています。） ああ、なんという長い旅だったろう。この会社で５年間もセキュリティを担当していたよ（諸々の失敗は許してくれ） 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、
Ｃプログラミング診断室
はじめに 開院準備 昔むかし／ レベル差／ 教育／ ネットワーク／ 情報集め／ 隠すことについて／ プログラムコンテスト／ ドキュメント／ 楽するように／ 手抜きと下手の違い／ 開院 第１部 外来 第１章 普通の初心者 最初から充実した(!?)プログラムが登場 関数を短くし、コメントを改善する 上手になる秘訣／ プログラムの紹介／ 何だ、このプログラムは!!／ 短くするには／ コメントについて／ 無駄な努力をやめよう／ 名前／ 気になる個所／ 修正プログラム／ 課題／ まとめ 第２章 これでもプロ 売りものであるにもかかわらず、超きたない！ 構造的な欠陥の指摘〜引数、ポインタの活用 プログラムの紹介／ 「超」基本的問題点／ 関数分解／ 構造的欠陥／ 引数を使おう／ ポインタ／ その他／ まとめ（修正プログラム） 第３章 上司が問題 まさに驚異的なプログラムの見本というべき 内容の修正から、
JavaScript：undefined値の判定
JavaScriptでは初期化されていない変数には全て「undefined」という値が入っています。 var a; alert(a); //undefinedが入っている これを利用して、変数が定義済みかどうかを判別することが可能です。…が、やり方がいろいろあるみたいなので、まとめてみることにします。 undefinedと比較する if (a === undefined) { alert("aは未定義"); } グローバル変数として、そのまんまundefinedという名前の変数が用意されているので、それと比較するやり方。一番素直な方法ですが、JavaScriptにおいては良くない書き方とされています。 undefinedは予約語ではなく、単なる変数です。だから上書きすることができるし、関数スコープ内で同名のローカル変数を作ることもできます。（ただし最近の処理系ではconst扱いになって上書
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
Redis 本番障害から学んだコードレビューの勘所
Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以
JavaScriptエンジニアなら知ってるよね？ エラー処理のいい書き方、悪い書き方
JavaScriptのエラー処理、ちゃんと書いていますか？ エラーを無視せず、どこに問題があるのか、きちんと確認できるコードの書き方をデモで紹介。 この記事はTim SeverienとMoritz Krögerが査読を担当しています。最良の記事を提供することができ、SitePointの査読担当者の皆さんに感謝します。 JavaScriptのエラー処理には危険が潜んでことを知っていますか？ もしマーフィーの法則を信頼しているとしたら、不具合が生じる可能性が本当に高いです！ この記事では、JavaScriptのエラー処理について考え、その落とし穴から便利な実践例までを説明します。さらに最後には、非同期コードとAjaxにも触れます。 JavaScriptはイベント駆動型プログラムで、プログラミングをより豊かなものにしてくれます。ブラウザーをイベント駆動型プログラムと考えると、発生するエラーは同一
コンピュータ・情報科学系で読んでおきたい本 - Books
コンピュータ・アーキテクチャ ◎コンピュータの構成と設計―ハードウエアとソフトウエアのインタフェース（上）（下） / (基本)(名著) ○コンピュータ・アーキテクチャ―設計・実現・評価の定量的アプローチ / (易)(コンパクト)(CPUの歴史あり)(読んでおきたい) ○マイクロプロセッサ・アーキテクチャ入門 / (難)(名著) ○CPUの創りかた / (萌え本)(読んでおきたい)(入門) コンピュータの構成と設計~ハードウエアとソフトウエアのインタフェース 第3版 (上) 作者: デイビッド・A.パターソン,ジョン・L.ヘネシー,David A. Patterson,John L. Hennessy,成田光彰出版社/メーカー: 日経BP社発売日: 2006/03/16メディア: 単行本購入: 14人 クリック: 356回この商品を含むブログ (89件) を見るコンピュータの構成と設計~ハー
ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
ブログをGatsbyの独自ドメインに移行しました。 今後のブログ記事更新は全てこちらのwww.jabba.cloudに書くつもりです。 はてなブログさようなら。今までありがとう。 かつてどこかで言ってしまってたかもしれないが、もう「ウェブサービスで１発当てる」なんて恥ずかしい発言はしない。 まずちゃんとウェブサービスをスケールさせている人達の中に「１発当てた」なんて人は絶対に居ない。それは不断の努力と度重なる失敗に続く失敗の中で改善を繰り返して到達したのは明らかだ。それを端から眺めて「俺も１発当たらないかなー」なんて、そうして本気でウェブサービスに取り組んでいる方達に対してあまりにも失礼だ。 だいたいそういう発言が出てくる発想そのものがダメだし、そんなこと言ってるヤツが本当に当てたところを見たこともない。 株式会社ピケの renさんの投稿を読むとウェブサービスをスケールさせるための覚悟が読
デザイナーとは職種ではなくマインドセットである
「シリコンバレーはすでに地域の名前ではなく、マインドセットである」これはシリコンバレーの著名VCであるAndreessen HorowitzのMarc Andreessenによるもの。今までに無い新しいアイディアを元に同じ情熱をもった仲間を集め，プロダクトを作成し、その夢に賭ける。 最近ではこの考えは、この地域以外にも世界中に広がり、”シリコンバレー的な考え方”として認知されている。 参考: シリコンバレーはただの場所ではなく、マインド（とコミュニティ）である We are all designersこれに近い考え方がここ数年でデザイナーにも広がっていると思う。我がビートラックスのコアバリューの一つに”We are all designers“がある。これは文字通り、”我々は皆デザイナーである“の意味。
プログラミング初心者がSICP(計算機プログラムの構造と解釈)を読んでみた - (wat-aro)
読む前の状態と動機 読み始めた時点でプログラミング歴約１年 もうひとつのscheme入門でプログラミングに入門するも，高階関数で挫折． Ruby本二冊，Rails Tutorialを二周． 他読み始めたけど途中で飽きた本が何冊か． 仕事（非IT)が忙しく，プログラミング始めて一年でこれくらいしか出来なかった． 基本的なところがしっくりこない． でもコード書くのは楽しいし，出来ればそれを仕事にしたいので基礎を身に着けたい． 無職になって時間もあるから基礎を身につけるためにSICPを読もう． 読むための準備 Scheme手習いとプログラミングGaucheを読んでからSICPにとりかかった． メインで読んだのは2版の和田訳．読んでわからない時は原著や1版の元吉訳に当たる． 後半になると真鍋訳が登場したためこちらにも助けられた． SICPを読む過程で得たもの 括弧が気にならなくなった S式のほうが
深さ優先探索による塗りつぶし
最小カットを使って「燃やす埋める問題」を解く方法について、問題とソースコードつきで、まとめました。ニコニコ生放送「TopCoderでプログラムしてみた」2000回記念放送の資料です。
startupでもrails使うなら これだけはやっとけ的 tips集 - Speaker Deck
All slide content and descriptions are owned by their creators.
仮説検証とサンプルサイズの基礎 - クックパッド開発者ブログ
パートナーアライアンス部 森田です。有料会員の獲得施策や、それに関わるサービス内動線の最適化を担当しています。 記事の対象 仮説検証を通じて何かを改善をしたいと思っている人 仮説検証の際に「どれくらいのデータを集めたら良いか」分からない人 はじめに 仮説検証とは「仮説を立て、それを証明するためのデータを集め、真偽を確かめること」です。今回は仮説検証を行う際の手順と、その検証に必要なサンプルサイズの考え方を説明します。サンプルサイズの話のみ関心があるかたは、前半を飛ばし「サンプルサイズの決め方」を読んでください。 目次 記事の対象 はじめに 目次 仮説検証のつくりかた 1. 仮説をたてる 2. 施策/KPIを考える 3. 仮説検証後のアクションを決める 4. 対象を決める 5. サンプルサイズを計算する サンプルサイズの決め方 答えを先に サンプルサイズを決める二つの要素 「二つの平均値」と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
優秀なエンジニアになる方法: 電子情報通信学会誌 Vol.84 No.10 pp.741-749 2001年10月
Ruby Hero Talk