先日、Yuji@勉強部屋さんと電話で話していて、文字クラスの理解が正規表現の「一里塚」だなぁ、と感じました。InDesignで初めて正規表現に接する方も多く、戸惑われている人もいらっしゃると思います。 文字クラスは正規表現の中でもちょっと特別な存在です。文字クラス内だけで使えるメタ文字や、位置によって意味が変わるメタ文字もあります。文字クラスについては、日頃使い慣れた人でも間違えやすい部分もあり、結構奥が深いのでおさらいの意味も込めてまとめておきます。 文字クラスの基本 ここで言う「文字クラス」は、「POSIXブラケット表現」とも呼ばれます。違うサイトや書籍などで、これらの用語が混在することがありますが、ほぼ同じと考えて差し支えありません*1。 文字クラスは任意の１文字にマッチする「文字集合」を表現できます。 簡単な例から見てみましょう。たとえば「お母さん」と「お父さん」のどちらにもマッチ

GitHubに400行以下で構成されたオペレーティングシステムが登録された。オペレーティングシステムは「resume_operating_system」と呼ばれている。開発の動機や仕組みなどに関する説明は「My resume in an Operating system」にまとまっている。オペレーティングシステムの基本構造を理解する際に役に立つ。 このオペレーティングシステムはMathieu Passenaud氏が学生時代に作成したオペレーティングシステムの基礎実装をまとめたもの。開発者の経歴を表示するだけという目的で作られた趣味的な取り組みの成果物であるため、明確に名称がついていない。GitHubに登録した名前が「resume_operating_system(経歴オペレーティングシステム)」であるため、この名称で呼ばれている。 resume_operating_systemではテキスト

Tell, Don't Ask は、オブジェクト指向プログラミングのよいとされる考え方の一つです。 Tell, Don't Ask は、日本訳で 求めるな、命じよ と訳されているのが、多いみたいですね。 オブジェクト指向というのは、役割を思ったオブジェクト同士が協力(コラボレーション)しながら機能(価値)を提供する。 オブジェクトが持つ役割が、あいまいだと良い設計と言われている 凝集度が高く結合度の低い ものは出来ません。 その為に、必要な考え方の一つなのが Tell, Don't Ask [求めるな、命じよ] である。 求めるな、命じよって言われてもピンきにくいですよね(´・ω・｀)w シーケンス図とか書いてみて、解説します。 Tell, Don't Ask Tell, Don't Ask とは、 Ask ではなく Tell しなさいというものです。 オブジェクトAが、オブジェクトBを呼

うーん、structural subtypingとダックタイピングは同じものなんだろうか。— Yukihiro Matsumoto (@yukihiro_matz) 2016年9月8日 https://t.co/5Rv86piThC wikipediaによると似て非なる物のようですね。 https://t.co/VwIg39h5M0— INADA Naoki (@methane) 2016年9月8日 この話題について補足しておきます。なお、僕はTAPL脱落組なのであまり正確性は期待しないでください。 背景 Ruby Kaigi で Matz が Ruby3 に向けて考え中の静的型について話されたようです。 少し前から、 Python でも Guido が Dropbox での大量のコードベースを改善していくために type hinting がほしいということで PEP 484 を始めました

Domain-Driven Design(DDD)と言えばエリック・エヴァンズの「ドメイン駆動設計」ですが、いろいろ調べてみると本当にDDDを行う上では更に多くの知識が必要だと感じたので、その動画と紹介されている書籍をメモ。 基本的に設計やデザインパターンに関する書籍が中心です。 タイトル 著者 初版 補足

こんにちは、fluct SSP開発本部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名（評価者）に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。（言うまでもなく、私は被評価者です） ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明

Photo credit: osde8info via VisualHunt / CC BY-SAソフトウェアの設計判断は多数存在しますが、大きな影響を与え続けているもの一つにUnixの哲学があります。本日は書籍『UNIXという考え方』で紹介されている定理の一つを紹介します。 定理２：一つのプログラムには一つのことをうまくやらせる 指針もなく機能の追加修正を続けていると、はじめは短かったコードも時間経過とともに混みいった醜いコードに変貌し、担当が抜けるとやがて誰も手が付けられない恐れや憎悪の対象となってしまいます。ここまでコードが悪化すると、市場からの予期しなかった重要な要望に対して俊敏に応えることは不可能になってしまいます。 そこで、本日ご紹介の定理です。一つのプログラムには、多数混ぜ込むのではなく、一つのことだけうまくやるように絞り込み、一つ一つの小さなプログラムを組み合わせて、達成し

読み終わった。たった100Pにプログラム言語を作るための基礎(字句解析、構文解析、ランタイム、インタプリタ、仮想マシン、ネイティブコンパイルまで！)が一通り学べ、さらに本書で作った実際に動くプログラミング言語がついてくる。 $39.99 とちょっと高いがプログラム言語を作る勉強代だと考えれば最も安くそして早く(ドラゴンブックは1090P)学べるのではないだろうか。洋書なのが難点だが半分くらいはソースコードなので苦労しながらなんとかなりました。(日本語訳出てほしいなぁ) 書籍内で作る言語は2種類で Awesome Rubyの構文にPythonのインデントブロックを混ぜ合わせたようなオブジェクト型 Mio Ioを参考にしたメッセージ型 言語自体はどちらもRubyで書かれているが紹介される概念は特に言語の制約を受けないものが多い。 よかったところ yaccやbison, JVM系の構文解析ツール

potatotips #28での発表内容です。 まだ試行錯誤中ですが、考えをまとめてみました。

http://eventdots.jp/event/591027 (2016-07-30追記：Rails 5.0からproductionでもDEBUGがデフォルトらしいです) (2020-09-23追記：https://github.com/rails/rails/pull/39707 INFOに戻りそう)

この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "半角カナ" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2023年11月） 半角カナ（はんかくカナ）、半角片仮名（はんかくかたかな, Halfwidth Katakana）とは、コンピュータで使用される文字集合のひとつで、もっぱら幅が通常の半分（半角）で表示または印刷される特殊な片仮名のことである。 日本におけるパーソナルコンピュータの黎明期から存在し、後に平仮名や漢字など多様な文字が利用可能になるまではコンピュータ上で日本の文字で日本語を書き表すことができる唯一の手段だった。 歴史[編集] ASCII普及前、大型コンピュータ（メインフ

実用的で無い内容なのでここで聞いて良いのか悩みましたが，一応クラスの設計の参考になるだろうと思って質問しました。 自分の普段使いがPythonなので，説明用のコードはPython風ですが，どの言語にも共通する問題だと思います。 先ほど友人と，「鶏肉を5つに切る」にはどうすれば良いかという例えばなしをしていました。 これを実装する場合， chicken.cut(5) # chickenは (Foodクラスを継承した) Meatクラスのインスタンス chef.cut("chicken", 5) # chefはChefクラスのインスタンス。あらかじめset_foodなどで{"chicken": chicken}を内部に保持した状態にしておく の2通りが考えられるのではないかと思います。 鶏肉の状態が変化するという意味では，「chickenが5つに分割された状態になる」前者の方が自然であるように思

Supershipの社内勉強会で使ったやつ

Nihal Sahuさんの2015年11月30日付のインタビュー記事An Interview with Elixir Creator José Valimの翻訳です。 全然技術的な投稿じゃないんですが(とはいえポエムでもないか)、Joséのアニキの言ってることがなかなかいい感じなので訳してみました。 。。。そういえばJoséってジョゼでいいの？ホゼなの？ホセなの？1 数週間前に遡ります。私はちょうどElixirを始めた頃でした。すごくハマってしまってIRCに飛び込んで質問しまくりで皆さんにご迷惑をお掛けしたかもしれません。私はElixirの作者であるJosé Valimにもいくつか質問しました。JoséはRubyコミュニティの人気者で彼にメッセージを送ったところとても親切に答えてくれました。いくつか質問したあと、これは彼にインタビューしてみないとな…と思いました。以下は会話の結果です。 あ

私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい

イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja