こんにちは。新卒1年目エンジニアのrs_shoです。 投稿は3回目になります。 今回は実装の際に気を付けるべき汎用メソッドの落とし穴についてお話ししたいと思います。 はじめに そもそも何に困ったのか 解決するためにどういう案があるのか おわりに 参考資料 はじめに 皆さん、 java でコーディングする時によく使うUtilsの便利なメソッド、コーディングが楽ですよね。 実装する際によくStringUtilsやNumberUtilsなど、色々な汎用メソッドを多用して 楽にコーディングできるので、ついつい使ってしまいがち。。。 そういう僕も良く汎用メソッドを使って実装することが多々ありますが、今回はそのメソッドを使った際に 困ってしまったお話をしようと思います。 そもそも何に困ったのか 僕は今回 org.apache.commons.lang.math.NumberUtils の isNumber を使用して、数値の判定をする部分のコーディングをしていました。 入力された値が数値なのかを判定してくれるメソッドです。 実装していて、実装後のテスト時にあれ？変だな。。。と思いました。 NumberUtils.isNumber() は普通の数値以外に 8進数 16進数 指数表記(科学的表記法) 型修飾子のついた数値 など、通常の数値(10進数)として扱うには、変換が必要な数値まで通してしまうのです。(2進数は文字列判定らしいです) これでは計算などをするためにキャストしたりする時に NumberFormatException などが出て困りますね。。。 解決するためにどういう案があるのか この問題を解決するためには、いくつか案はありましたが、どれが一番正しいのか、かなり迷ってしまいました。 僕の主観でですが、考えた案をメリット・デメリットを含めてお伝えしたいと思います。 * 変換をして変換できなかったらエラーを出す(try-catch文) * メリット * 必要な数値だけ選んで取れるほか、エラーのカスタマイズが容易(数値の型指定やエラーをcatchの中で設定できる) * デメリット * エラーを握りつぶすことになる(実装ではなるべくしない方が望ましい。。。) * try-catch文はパフォーマンスが落ちる(調べた範囲でですが、色々なクラスに遷移するので遅い) * 自分でメソッドを作ってしまう * メリット * 自分で書くので、必要な処理だけ書ける * デメリット * 開発コストがかなりかかる(汎用メソッドを補うため、考慮すべき点が多すぎる) * 考慮漏れがある可能性大(自分でコードを書くため、考慮漏れが発生しやすい) * 正規表現で数値かどうかを判定する * メリット * 正規表現が扱えれば自由度が高い * デメリット * (あくまで主観ですが)可読性が悪い、コードが汚く見える * 判定する文字列が長ければ長いほどパフォーマンスが落ちる 色々調べた結果、どの実装にもメリット・デメリットがあり、実装の内容によりけりって感じですね。。。 ちなみに僕はtry-catchと 正規表現 を使用しました。 考慮漏れを防ぐためにも、ある程度組み合わせたほうが安全だと思います。 おわりに いかがでしたか。僕はこの問題に直面してからコーディングにものすごく時間を使いました。 みなさんのコーディングの助けになれば幸いです。 参考資料 基本的な正規表現一覧 | murashun.jp あえて言うほどではない　数値変換時の型チェック Java編

はじめに はじめまして。新卒1年目のtuq376sです。 気付けば入社してから季節は4つ目。毎日新しい壁にぶつかりながら、それでも随分とわかることが増えたなぁと思うくらいには成長できている気がします。 今回はそんな壁の中から、初めて シェルスクリプト を業務で触った時のことをまとめてみようかと思います。 はじめに 読めそうで読めなかったシェル 学んだこと 特殊パラメータ if文の条件式 testコマンド リダイレクト ファイルディスクリプタ さいごに 読めそうで読めなかったシェル シェルスクリプト に関するタスクを割り振ってもらったのは、少しずつ業務に携わり始めて、普段使っている Java の至極簡単な修正であれば1人でも頑張れるようになり始めたころ。 今まで触れたことがなかったとはいえ、 シェルスクリプト の概要は研修でも学んだし、改修する内容も既存に合わせて分岐を1つ増やすだけだったのでなんとかできそうだと思っていました。 一応新卒1年目とはいえエンジニアの端くれ、実際コードを見てどこをどうすればいいのかはすぐわかったのです。……けれど同時に、読めているのは雰囲気だけだなということにも気づきました。 いくら簡単なタスクとはいえ流石にそんな中途半端ができるわけもなく。ものの30分もしないうちに、まずは基礎の基礎を知ろうと思ったのでした。 学んだこと 特殊パラメータ シェルスクリプト を見てまず思ったのは$が多いということ。眺めていれば ${hghg} は変数で、 $1 や ${10} はこのプログラムへの引数だろうというのは見当がつきました。 けれどいくつか記号と組み合わさっているものについてはわからず、真っ先に調べることに。 どうやら特殊パラメータと呼ばれるもののようで、調べた中から自分でもぱっと理解して使えそうなものから覚えることにしました。 特殊パラメータ 内容 $@ 渡された引数全て。区切り文字は空白 $# 渡された引数の個数 $$ シェルのプロセスID $? フォアグラウンドで最後に終了したコマンドステータスの値 $! バックグラウンドで最後に終了したコマンドプロセスのID よく見る $HOME や $PATH のように予約された変数ということですね。 流石に記号だとどのような意味かは見ただけで推測できないので、わからなくなったら自分でここを見返そうかと思います。 if文の条件式 次にif文。これは雰囲気でも読めてしまうので書き方が違うだけだな……と思っていたのですが。 if [ ${a} -ne ${b} ]; then 処理 fi 条件式の中にコマンドのオプションらしきものを見て、これもわからないとなったわけです。 調べるとどうやらif文の条件式は本来testコマンドを使うようで、 [条件式] はtestコマンドの書き方の1つだとか。 testコマンドについても最低限しか知らなかったため、再度おさらいをすることになりました。 testコマンド 条件を判定し、真偽を返すコマンドです。 test 条件 または [ 条件 ] と表記します。 条件に使用するオプションは数多くありますが、一般的な数値処理と論理処理に関するものは以下になります。 オプション 意味 -eq == (equal) -ne != (not equal) -lt -le -gt > (greater than) -ge >= (greater than or equal) -a && (and) -o || (or) こちらは英語の省略系なので、わかっていれば毎度調べなおすこともなさそうですね。 リダイレクト さてもう1つ、読んでいて全然知らない……となったのはリダイレクトを行っている部分でした。 `コマンド` > ファイル名 2>&1 上記のような表記になじみがなかったのですが、これはファイル ディスクリプタ を利用して、標準出力と 標準エラー出力 を同じファイルに書き込んでいるらしい。 まずファイル ディスクリプタ とはなんだったっけ……ということでこれもまたおさらいしました。 ファイル ディスクリプタ ファイル ディスクリプタ とはOSがファイルを識別するために割り当てる管理番号のことで、各ファイルの名前や属性などが参照できるように結び付けられています。 普段ユーザがこの番号を意識することはありませんが、予約されている番号に関しては時々見かけることがあるようです。 番号 内容 0 標準入力 1 標準出力 2 標準エラー出力 内容を見ると、ああそれかとはなるのですが、普段見かけていないとすぐ忘れてしまいますね……。 これを踏まえてさっきの記述を解釈すると、 `コマンド` > ファイル名 2>&1 コマンドが実行され、標準出力をファイルにリダイレクト (標準出力をするときの ディスクリプタ 番号は省略可) 標準エラー出力 を標準出力へリダイレクト 標準出力はファイルにリダイレクトされているため、 標準エラー出力 もファイルへ書き出される ということのようです。もちろん上書きではなく追記を行う >> についても同じように使うことができます。 さいごに というわけで基本的な最低限を調べた私は、なんとかコードをきちんと理解したうえでタスクをこなすことができたのでした。 今回記事にまとめるにあたって、その時に調べたことをもう一度きちんと調べたのですが、そのおかげで 「読めるようで読めなかったシェル」も「読めないようでちょっとだけ読めるシェル」くらいには親しくなれたような気がしています。 これからも業務で触る機会はそこそこにありそうなので、少しずつ「読める！」と断言できるようになっていきたいなと思います。 そして、動作確認前に改めてコードを読み直してみたら思った以上に改修の必要な範囲が広くて顔を青くしたのはまた別のお話……。

@kawanamiyuu です。この記事は「 ドメイン駆動設計#1 Advent Calendar 2019 」の 6 日目の記事です。 1. はじめに 2. ドメインの依存関係に対するアーキテクチャテスト 2.1. 人事労務管理システムのドメイン 2.2. ドメインの依存関係 2.3. ドメインの依存関係に対するアーキテクチャテスト 3. レイヤーの依存関係に対するアーキテクチャテスト 3.1. シンプルなレイヤーアーキテクチャ 3.2. 依存関係を逆転したレイヤーアーキテクチャ 4. さいごに 1. はじめに 最近、技術イベントやまた社内でも「 ドメイン 駆動設計」や「クリーン アーキテクチャ 」についての話題をこれまでにも増してよく耳にするようになりました。 私も 楽楽労務 という実際のプロダクト開発で 1 年以上、 ドメイン 駆動設計に取り組んできました。 ドメイン 駆動設計 ﾁｮｯﾄﾃﾞｷﾙ ような気がしてきたころ、このように思いました。 「 ドメイン 駆動設計って、『 オブジェクト指向設計 をちゃんとやる』ってことだよね？」 ドメイン 駆動設計もクリーン アーキテクチャ も、 オブジェクト指向設計 原則のうえに成り立つ設計プ ラク ティスであり、ただ、重要な視点として、 オブジェクト指向設計 原則の適用を検討する対象がクラスだけではありません。もう少し大きな単位、パッケージ・モジュール・レイヤー、まで視野を広げます。 依存関係が注意深く設計され、単一の責任を持ったモジュールやパッケージが、 ドメイン をかたちづくります レイヤーやパッケージの依存関係の逆転により、 ドメイン は自身の関心や責務を逸脱することなく ビジネスロジック の実現に集中できます ドメイン 駆動設計が オブジェクト指向 プログラミングによって実現されるということは、その アーキテクチャ も、私たちが慣れたいつもの方法 ─ ユニットテスト ─ で、テストすることができます。 ソースコード も アーキテクチャ も、一度つくって終わりではありません。プロダクト開発が続くかぎり、常に見直され改善されるべき対象です。 ...... 前置きが長くなりましたが、この記事では 依存関係 という切り口から、 アーキテクチャ の品質を継続的に維持・改善していくための手法として、 ArchUnit ( Java ) による アーキテクチャ テストを紹介します。 github.com ArchUnit って何？については昨年の アドベントカレンダー に投稿しています。 qiita.com 2. ドメイン の依存関係に対する アーキテクチャ テスト 今回は、私が開発を担当している人事 労務管理 システムを例にします。人事 労務管理 システムとは文字通り、企業の人事 労務 担当者の業務を 楽 にするための業務システムです。 このシステムが扱う業務の 1 つである、「従業員の入社関連業務」は以下のようなものです。 会社に従業員が入社したときに、従業員情報（氏名や住所といった個人情報、 基礎年金番号 といった 社会保険 に関する情報、など）を収集する 入社後、社内申請フローにより追加の個人情報が収集され、役所への 社会保険 等の提出書類（届出書という）を作成するための行政手続きフローが開始される 行政手続きフローを進めることで、（複数の）届出書が生成される 2.1. 人事 労務管理 システムの ドメイン 業務 ドメイン の境界が比較的わかりやすく、大きく 4 つに分けられます。 従業員 ドメイン （ employee ） 社内申請 ドメイン （ request ） 行政手続き ドメイン （ procedure ） 届出書 ドメイン （ report ） これらの ドメイン を Java プロジェクトのパッケージとして表現すると以下のようになります。 2.2. ドメイン の依存関係 ドメイン 同士の依存関係は次のとおりです。 「従業員 ドメイン 」（いわゆる 従業員マスタ を含む）は、人事 労務管理 システムという特性上あらゆる ドメイン から参照されます 「社内申請 ドメイン 」は、後続の業務であるの「行政手続き」を知っています 「行政手続き ドメイン 」は、その手続きで必要となる「届出書」を知っています 2.3. ドメイン の依存関係に対する アーキテクチャ テスト ドメイン の依存関係に対する アーキテクチャ テスト（以下の例は一部）は ArchUnit で次のように実装できます。 private static final JavaClasses CLASSES = new ClassFileImporter() .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS) .importPackages( "com.example" ); @Test void 従業員ドメインは他のドメインに依存しない() { noClasses().that().resideInAPackage( "com.example.domain.employee.." ) .should() .dependOnClassesThat( new DescribedPredicate<>( "従業員ドメイン以外のドメイン" ) { @Override public boolean apply(JavaClass input) { if (! input.getPackageName().startsWith( "com.example" )) { // プロジェクト外（サードパーティライブラリ等）への依存はOK return false ; } return ! input.getPackageName().startsWith( "com.example.domain.employee" ); } }) .check(CLASSES); } @Test void 社内申請ドメインは届出書ドメインに依存しない() { noClasses().that().resideInAPackage( "com.example.domain.request.." ) .should() .dependOnClassesThat().resideInAPackage( "com.example.domain.report.." ) .check(CLASSES); } @Test void 行政手続きドメインは社内申請ドメインからのみ依存される() { classes().that().resideInAPackage( "com.example.domain.procedure.." ) .should() .onlyBeAccessed().byAnyPackage( "com.example.domain.request.." ) .check(CLASSES); } 3. レイヤーの依存関係に対する アーキテクチャ テスト ドメイン 駆動設計の文脈でよく登場する アーキテクチャ として、「レイヤー アーキテクチャ 」があります。ArchUnit でレイヤー アーキテクチャ に対するテストは以下のように実装できます。 ※この記事では省略しますが、オニオン アーキテクチャ （ヘキサゴナル アーキテクチャ ）に対するテストも ArchUnit で実装できます。興味のある方は User Guide を参照ください。 3.1. シンプルなレイヤー アーキテクチャ 上位の層が下位の層に依存します。 @Test void シンプルなレイヤーアーキテクチャ() { layeredArchitecture() .layer( "ui" ).definedBy( "com.example.presentation.." ) .layer( "app" ).definedBy( "com.example.application.." ) .layer( "domain" ).definedBy( "com.example.domain.." ) .layer( "infra" ).definedBy( "com.example.infrastructure.." ) .whereLayer( "ui" ).mayNotBeAccessedByAnyLayer() .whereLayer( "app" ).mayOnlyBeAccessedByLayers( "ui" ) .whereLayer( "domain" ).mayOnlyBeAccessedByLayers( "ui" , "app" ) .whereLayer( "infra" ).mayOnlyBeAccessedByLayers( "ui" , "app" , "domain" ) .check(CLASSES); } 3.2. 依存関係を逆転したレイヤー アーキテクチャ ドメイン 層とインフラスト ラク チャ層の依存関係（依存の方向）を逆転させることで、 ドメイン 層はどの層にも依存せず、 ドメイン 層に閉じて ビジネスロジック の実現に専念できます。 @Test void 依存関係を逆転したレイヤーアーキテクチャ() { layeredArchitecture() .layer( "ui" ).definedBy( "com.example.presentation.." ) .layer( "app" ).definedBy( "com.example.application.." ) .layer( "domain" ).definedBy( "com.example.domain.." ) .layer( "infra" ).definedBy( "com.example.infrastructure.." ) .whereLayer( "ui" ).mayOnlyBeAccessedByLayers( "infra" ) .whereLayer( "app" ).mayOnlyBeAccessedByLayers( "infra" , "ui" ) .whereLayer( "domain" ).mayOnlyBeAccessedByLayers( "infra" , "app" ) .whereLayer( "infra" ).mayNotBeAccessedByAnyLayer() .check(CLASSES); } 4. さいごに ドメイン 駆動設計とは、特別な 銀の弾丸 的な設計手法ではなく、 オブジェクト指向設計 という基本的かつ重要なプログラミング原則のうえに成り立つ設計プ ラク ティスです クラスだけではなく、レイヤーやモジュール・パッケージといった粒度でも依存関係を注意深く設計し、依存関係を管理していくことが重要で、 ソースコード も アーキテクチャ も一度つくって終わりではなく、常に見直され改善されるべき対象であり、 アーキテクチャ も継続的にテストすることができます ドメイン 駆動設計、やっていきましょう！ ...... tech-blog.rakus.co.jp

こんにちは、 @whiteFox_73 です。東京で11/30～12/1に開催された JSConf JP に登壇してきました。 また、株式会社 ラク スはJSConf JPの BRONZE スポンサーとしてイベントに協賛いたしました。 イベント概要 日時：2019年11月30日（土）～ 2019年12月1日（日） 会場：アーツ千代田 3331 公式 HP： https://jsconf.jp/2019/ jsconf.jp 登壇 正攻法はあるのか!?泥臭く戦ったNode.jsバージョンアップ一部始終（30分セッション） speakerdeck.com 初めての登壇がJSConf JPというのは緊張しましたが、無事発表することが出来ました。 発表内容としては、弊社サービス「 チャットディーラー 」で利用しているNode.jsをメジャーバージョンアップした方法やその際の苦労話を中心にお話しました。 実際の体験談的な発表は比較的少なめだったので、興味持ってもらえるか心配していたんですが、 発表後に Twitter を見たところ、共感してくれるコメントなどがありホッとしております。 全機能テストで複数回サイクル回すのあるよねー 営業日や平日・休日で挙動が異なるシステムなら尚更 この泥臭さ、弊社感あるｗ #jsconfjp #jsconfjp_b — ちゃんちゃん@雑食エンジニア (@fashioncrazy66) December 1, 2019 今回の発表資料を作るにあたっていくつか苦労したところがありました。 一つ目は当初話そうとしていた内容では30分枠に収める事ができず、資料のボリュームを落とすことになったところ。 ストーリー性を損なわずに削る作業が難しかったですが、一番伝えたかった 泥臭い 作業や、トラブルを経験して Node.jsの知見を得れた というところは伝えられたかと思います。 資料からは省きましたが当初の案では、 負荷試験 の話やNode.jsバージョンアップに伴うアプリ側の改修の話などがありました。 本番の資料は70枚ほどでしたが、延べ150枚ほど作った気がします(笑) 二つ目は発表内容の出来事は1年～半年前の出来事なので思い出すのに苦労したところ。 幸い、トラブルの過程などを自分用にまとめたドキュメントが作ってあったので何とか思い出せました。 やはり、こういった資料を作る際は時間が経つ前に書くべきと反省です。 印象に残ったセッション 興味を惹かれるセッションばかりでした。 参加した中でも特に印象に残ったセッションを中心に紹介します。 JavaScript AST プログラミング: 入門とその1歩先へ jsconf.jp ESLintなどを利用したことはありましたが、内部で使われている JavaScript ASTに関してはどういったものかよく知らなかったので参加しました。 JavaScript ASTは JSON で表現されるということもあり、理解しやすかったです。 ライブコーディングを見るのは初めてでしたが、普通の発表よりも自分ならどうしたいかイメージしやすくわかりやすいと感じました。 セッションを聞いて、チーム内だけのコーディング規約などは JavaScript ASTを利用して書き換えた方が早そうな気がしました。 簡単なものであればすぐ作れそうな所もポイント高い。 他には、自分が頻発させてしまう ケアレスミス とかにも利用できそうだなと。(笑) Streams API をちゃんと理解する speakerdeck.com セッションの最後の方に話されていましたが、この辺りの技術は今後重要になりそうです。 ５Gなど通信技術が発達し大容量データのやり取りが増えそうなので、データを分割しないとクライアント側が耐えきれない…という状況は容易に想像ができる。 図が凄く見やすかったので見習いたい!! Minimum Hands-on Node.js speakerdeck.com 今までNode.jsは独学でやってきたのでhandsonに興味があったので参加しました。また、社内でこれからNode.jsを学習する人がいたので参考になればという思いもありました。 全体を通して凄く分かりやすかったので社内でも紹介したいと思います。 標準モジュールの学習するおススメの順番はNode.jsを触り始めた頃に知りたかった!!(笑) 途中で他社がどのように運用しているかなどの話を聞ける場面があり、今まで情報を得る機会が少なかったのでいろいろと勉強になりました。 handsonの 進捗管理 に調整さんを利用する発想はなかったので、面白い発見です。 感想 様々な方に発表練習や資料作成にお付き合い頂いたおかげで本番の発表に漕ぎつける事ができました。 ご協力いただいた皆様、本当にありがとうございました!! イベント中は技術的な質問をすることやされることが多々ありとても刺激になりました。 一つ後悔しているのは、海外のエンジニアと話ができる機会なのに英語が苦手であまり話せなかった事です…。 次の機会があれば話せるように頑張ります。(笑) 最後に、JSConf JPに参加したことで多くのエンジニアと知り合う事や貴重な体験ができました。 参加させてくれた会社とJSConf JPの運営の方々に感謝申し上げます。 おまけ 凄い共感して撮ってしまった。

はじめに はじめまして、新卒1年目エンジニアのthree_yagiです。 入社から早くも8か月が過ぎ、ようやく業務にも慣れてきました。業務において Linux を操作することが度々あり、はじめは何か操作しようとする度にコマンドなどを調べていましたが、最近は基本的な操作なら検索サイトを頼らなくても出来るようになってきました。 Linux の パーミッション については入社後の研修で Linux のマニュアルを読んで基礎から学習しました。最近、その パーミッション を意識する機会があったので、自身の復習も兼ねて基本をまとめてみました。また、意外と見落としがちなファイル削除時の パーミッション の注意点について紹介します。 目次 はじめに 目次 パーミッションとは パーミッションの見方 ファイルの削除権限 スティッキービット まとめ パーミッション とは Linux ではファイルと ディレクト リに対して、誰がどういった操作ができるかの権限を設定することができます。この設定を パーミッション といいます。 パーミッション は、「ファイルの所有者」「所有グループ」「その他ユーザー」という３種のユーザータイプに対してそれぞれ「読み取り」「書き込み」「実行」の権限を割り当てることができます。 パーミッション の見方 では実際に ls -l コマンドで パーミッション を確認してみましょう。 $ ls -l -rw-r--r-- 1 user group 0 12月 3 14:28 2019 test drwxr-xr-x 2 user group 4096 12月 3 14:28 2019 test_dir それぞれの行の先頭の10文字がそのファイル/ ディレクト リの パーミッション を表します。 はじめの1文字：ファイルの種別 "d"： ディレクト リ "-"：ファイル 2~10文字目：それぞれのユーザタイプにおける権限 最初の3文字分がファイルの所有者の権限 次の３文字が所有グループのユーザーの権限 最後の3文字がその他ユーザーに対する権限 権限の記号の意味と、権限を持つユーザーがファイル/ ディレクト リに対して行える操作を以下にまとめます。 記号 意味 ファイル ディレクト リ r 読み込み ファイルの内容を表示 ディレクト リ内のリスト表示 w 書き込み ファイルの上書き、変更 ディレクト リ内にファイル作成、削除 x 実行 実行ファイルの実行 ディレクト リ内に移動 上の実行例では、"test"ファイルは所有ユーザーはファイルを表示した上で編集を行えますが、所有グループのユーザーやそれ以外のユーザーはファイルの表示しかできません。 このように パーミッション を設定することでユーザーのタイプ別に操作を制限することができます。 次にファイル削除における パーミッション の注意点を説明します。 ファイルの削除権限 たとえば以下のような ディレクト リがあったとします。 drwxrwxrwx 2 user group 4096 12月 3 14:28 2019 free_dir すべてのユーザーが「読み取り」「書き込み」「実行」が可能な ディレクト リですね。 ではこの ディレクト リ内に以下のファイルが存在するとき、「その他のユーザー」はこのファイルを削除できるでしょうか。 -rw-r-x--- 1 user group 128 12月 3 14:28 2019 testfile 「その他のユーザー」はこのファイルに対して何の権限も持ちません。そのため削除できない。と考えてしまいそうになりますが、実際は削除できてしまいます。 上のrwxの表にでも示しているように、ファイルの削除は ディレクト リの書き込み権限で制御されています。そのため、 ディレクト リの書き込み権限を持つユーザーはファイルに対する権限を何も持たなくても削除ができてしまうのです。 ディレクト リの書き込み権限をなくせば削除を制限することができますが、同時にファイルの新規作成もできなくなってしまいます。 スティッキービット では、ファイルの作成を許可しつつ、削除を制限したいときはどうすればよいでしょうか。 その場合は、スティッキービットを使用します。 ディレクト リにスティッキービットを付与すると、その ディレクト リ内のファイルは所有者以外が削除できなくなります。 スティッキービットは以下のコマンドで付与できます。 $ chmod +t free_dir スティッキービットが付与された ディレクト リは ls -l コマンドで以下のように表示されます。 drwxrwxrwxt 2 user group 128 12月 3 16:42 2019 execute_dir パーミッション の最後に"t"が追加されていることがおわかりでしょうか。 この記号がスティッキービットを表しています。 この状態で所有者以外のユーザーが ディレクト リ内のファイルを削除しようとすると、下記のようなメッセージが表示され、ファイルが削除できなくなっていることがわかります。 $ rm testfile rm: remove write-protected 通常の空ファイル `testfile'? y rm: cannot remove `testfile': 許可されていない操作です ファイルの削除を制限する機会はそれなりにあると思うので、スティッキービットの設定方法は覚えておきましょう。 まとめ Linux における パーミッション とその注意点についてまとめてみました。 パーミッション の変更方法やumaskなど、まだまだまとめておきたいことはありますが、キリがなさそうなのでいったんここで締めようと思います。 パーミッション は Linux の基礎的な知識ではありますが、 Linux 上での様々な操作や処理にかかわってきます。 プログラムを実行したらエラーが出たけど原因がわからない…というときは一度 パーミッション をチェックしてみてもよいかもしれません。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

id:radiocat です。先日ご紹介したとおり私たちは大阪オフィスで『Web× PHP TechCafe』という新しいイベントをスタートさせました。今回はこの流れに至るまでのコミュニティ運営についてご紹介します。 tech-blog.rakus.co.jp もともとは『もくもく勉強会』としてスタートしたイベントでしたが、様々な試行錯誤や葛藤の末に今の形にたどり着きました。今回はその振り返りと新たなスタートの意味で 「 Web × PHP TechCafe Advent Calendar 2019 」の記事として書くことにしました。同じようなイベントやコミュニティに関わる方々の参考になれば幸いです。 チームの仲間に呼びかけてイベント立ち上げ スタートは2018年のオフィス移転でした。このとき、念願がかなってオフィス内に セミ ナールームとして活用できるスペースを作ってもらうことができました。 tech-blog.rakus.co.jp 特に目指すべきゴールなどは設定せず、ただやってみたいという思いで当時のチームメンバーに声をかけてスタートしました。実際に運営側として取り組んでみると、それまで参加側では気づけなかったことに色々と気づきました。スタートした最初の数ヶ月で当時気づいたことをいくつかご紹介します。 タイトルに大阪・梅田を入れる 我々は connpass を使って参加者を募集しています。人口比率的に東京を中心としたイベントが多いので、大阪・梅田で開催することをなるべくわかるようにしなければ、認知すらしてもらえませんでした。そこでタイトルに「大阪・梅田」という開催場所を入れるようにしました。これは関西や他の地方のコミュニティの多くで実践していることだと思います。 枠数と席の配置を考える 実際の参加者に対して多すぎず、少なすぎない枠を予測して設定するほうが良いとわかりました。余裕を持って確保しすぎるとガラガラな寂しい状態になり、枠を絞りすぎると参加を見送る人が出てくる可能性もあるので、毎回予測を立てながら最低限のスペースや席を確保してスタートし、エントリー状況を見守りながら最終的なスペースや席を決めています。私たちのイベントはただ黙々と勉強するだけではなく、参加者同士の交流も大切にしたいため特に気をつけています。 お菓子を置く 一般的に、食べ物の存在は交流しやすい雰囲気を生み出すとよく言われているので、お菓子を確保してご提供するようにしました。小さくスタートしたこともあり潤沢に準備はできていませんが、よくある懇親会のような大規模なものではないので、もくもく勉強会のお供や参加者の交流に必要な量としてはバランス良く成り立っていると感じています。 次回の募集を開始 毎月1回開催を決めており、気に入ってもらえた参加者のかたには次回も是非参加してもらいたいという思いで、開催当日には必ず次回の募集を開始し、開催を告知しています。 立ち上げ成功、運営体制の強化 約半年間の取り組みの結果、毎回一定の方々に参加してもらえるようになり、社内でも認知されてきたため、各チームからイベント運営のメンバーを選出してもらい正式な体制を作って運営できることになりました。 最初の3ヶ月の参加者数 社内ですでに実施していたMeetupなどの他のイベント運営とも連携して存在意義と活動範囲が拡大しました。 1年でモチベーション低下、マンネリ化 スタートしてから1年後、運営チームのふりかえりでモチベーションをタイムラインに表現してみたところ、全員が直近のモチベーションが下がり気味であることがわかりました。 原因についてディスカッションしたところ、いくつかの課題が見えてきました。 社内の参加者とのギャップ 社内では比較的いつでも使えるスペースなので、社内の参加者は毎月決められた日程に合わせてわざわざ自主的な勉強会をすることにあまり強い動機がなくなってきました。 参加者と運営側のギャップ 運営メンバーはイベントを運営しながら技術的な情報交換をしたり、エンジニア同士の交流を行うことも強い期待を持っていました。そのためもくもく勉強会の自習要素が高まると、運営者は場のセッティングなどが中心になりマンネリ感が高まってしまいます。 そろそろ新しいことをやりたい 集まった運営メンバーはそれなりに意欲を持って集まっているので、毎回同じように運営するだけの状況に疑問を感じ始めていました。何か新しい要素を取り入れてもっと活動範囲を広げれないかと考え始めていました。 PHP のエンジニアが交差するTechCafeへ これらの課題を踏まえて、運営していく我々にできることは何かをもう一度考えてみました。私たちの会社を当初からずっと支えてきたサービスは PHP で開発しており、 PHP に関しては組織体制上、その技術はほぼ大阪に集中しています。曲がりなりにも20年近くお客様へサービスを提供しており、 PHP に関してはある程度の強みを持てていると考えています。 ラク スと PHP について これを踏まえて、私たちはただ単に勉強する場をご提供するだけでなく、もっと能動的に学びとなる場をつくっていきたいと考えました。 TechCafeが支える領域 そして、その目的を 言語化 し「 PHP を軸としてエンジニアと技術が交差する憩いの場（カフェ）になる 」というコミュニティのコンセプトが生まれました。 Web× PHP TechCafeのコンセプト まだまだスタートしたばかりで、引き続き試行錯誤が続いていますが、いくつか新しく始めた取り組みを紹介します。 ディスカッション枠 先月は PHP 7.4の新機能について興味を持った人が集まってその仕様を把握したり、使い方やメリット・デメリットなどをディスカッションしました。思った以上に盛り上がって、次回も継続する予定です。なお、これらの情報はコミュニティ専用の Slack でも共有しています。 LT枠 また、5分のLT枠も作りました。特にテーマは決めず、普段参加して頂いている方の成果発表やアウトプットの機会として頂きたいと考えています。 コミュニティ間コラボ その他、関西で PHP を扱っている他のコミュニティともコラボして PHP 界隈を盛り上げていきたいと考えています。コミュニティ関係者のかたでご賛同いただけるかたがいらっしゃればぜひご連絡をください。 色々と新しいことに取り組み始めた段階で、ひとつひとつはまだまだ小さな取り組みですがこれから拡大していきたいと思います。 PHP 好きのみなさんよろしくおねがいします。

はじめに はじめまして。新卒一年目エンジニアのnr_1228です。 入社してから半年以上がたち、コードとにらめっこすることが多い日々を過ごしていますが、入社当初に比べると少し余裕をもって業務を行うことができるようになったと感じます。 そんなコードとにらめっこする日々の中で、自分が発表する機会や、人の発表を聞く機会も増えました。 Keynote 、 PowerPoint 、 Google スライドでの発表を見ている中でふと、違う見た目で発表している方が・・・。 大学時代にもそんな発表をしていた人がいたことを思いだし、 気になったので調べるとreveal.jsを使っているらしく、実際に作ってみると思っていたよりも良かったので紹介します。 目次 はじめに 目次 reveal.js reveal.jsとは 特徴 書き方 おわりに reveal.js reveal.jsとは reveal.jsとは、 JavaScript のプレゼンテーション作成 フレームワーク で、HTMLや markdown でスライドを作成することができます。 GitHub から reveal.js を clone してくる Visual Studio Code を使って 拡張機能 をインストール これだけでできてしまうんです。 Visual Studio Code で作成すると以下のようにプレビューを見ながら作成をすることができ、どのような見た目になっているのかすぐに確認することができます。 実際の画面 特徴 いろいろな特徴がありますが、良いなと思った点を以下に挙げます。 HTMLでスライドを作成してブラウザ上でプレゼンを実行できる Markdown で作成可能 4方向にスライド遷移 ESCボタンを押すとページの一覧も見れるので、ページを探すときに便利 PDFにするのもURLに ?print-pdf を付けるだけでできてしまう fragment を使えば簡単なアニメーションも付けることができる 文字で説明されただけではわからないという方、 以下の公式サイトを見てみてください。 今までの説明が要らないくらい、いやそれ以上に理解することができると思います。 revealjs.com 書き方 書き方などど見出しを作っていますが、 Markdown を書いたことがある方はすぐに作成できると思います。 覚えることは、 一つだけ 。 ページの区切りに --- を入れることだけです。 reveral.jsの特徴である、縦方向への切り替えは -- を入れるだけ！ 後は Markdown でがっつり内容を書いていきましょう。 以下は試しに書いたものの1ページです。 このページのコードは --- ## シンタックスハイライト ``` function class{ $number1 = 100; if ($number1 >= 50) { print("number1があります"); } } ``` highlight.jsによるハイライトが自動で行われる --- たったこれだけ。 書き方に慣れたら、htmlを使い表現の幅を広げることができます。 例えば、 <span style="color:red">色</span> <span style="font-size: 150%">サイズ</span> <div style="text-align:left">左寄せ</div> と書くだけで 　 このようなレイアウトになるのです。 詳しくは、公式のredmeを読んでみてください。 github.com おわりに reveal.jsを使ったスライド作りについてまとめてみました。 普段から Markdown で文章を書く人からすると書くだけでスライドになってしまう便利なものだと思います。 Markdown でメモしているものをサクッとスライドにすることができてしまうので、 スライド作りに時間がかかってしまう人は日ごろ Markdown でまとめたりしていると、スライド作りにかける時間を大幅に短縮できるようになると思います。 私もこの方法でのスライド作りに慣れ、資料作成に費やしている時間を減らしていけたらと思います。 この記事を読んで少しでも興味がわいたという方がいらっしゃいましたら、 是非実際に作ってみてください。

はじめに 初めまして。新卒1年目エンジニアのdd_ fortran です。 業務で PHP を使い始めて4ヶ月が経ちました。私は学生時代は C言語 や Fortran 、新人研修では Java を使用しており、 PHP に触れるのはこれが初めてでした。これまで コンパイラ 言語に多く触れてきたため、はじめてインタプリンタ言語に触れ戸惑いが多くありました。 本記事では、 PHP 初心者の私が戸惑ったことについてまとめようと思います。 目次 はじめに 目次 戸惑ったこと 変数の暗黙の型変換 戻り値の型が不定 その他 bindValue()とbindParam()の違い まとめ 戸惑ったこと まず、初めに PHP を学習して戸惑ったことは変数についてです。 今まで学習してきた言語と変数の扱いが大きく異なり、慣れるまで時間が掛かりました。 変数の暗黙の型変換 暗黙の型変換とは、 PHP が変数をオートキャストしてくれることです。 (便利ですね) <?php $ str = "2" ; $ int = 5 ; $ result = $ str * $ int ; // $result = (int) 10 ?> 上記の場合、「$str = (int) 2」のようにオートキャストされ計算されます。 一見、便利のようですが次の場合には不具合が発生してしまう可能性があります。 <?php $ str = "2abc" ; $ int = 5 ; $ result = $ str * $ int ; // $result = (int) 10 ?> 上記のような実装はすることはないと思いますが、フォームの内容などは文字列として取得されるため比較する際には注意が必要です。 緩やかな比較と厳密な比較 PHP には、緩やかな比較(==)と厳密な比較(===)があり緩やかな比較では型がキャストされてから比較され、厳密な比較では型がキャストされずに比較されます。 例えば次のような違いがあります。 <?php $ str = "1" ; $ int = 1 ; if ( $ str == $ int ) { } // true if ( $ str === $ int ) ( } // false ?> 緩やかな比較と厳密な比較に注意して実装する必要があります。 PHP の公式ドキュメントに PHP 型の比較表 があるので、比較の結果が分からなくなった場合にはこれを参考にするとよいでしょう。 戻り値の型が 不定 PHP では戻り値の型が必須ではありません。 例えば次のような実装が可能になります。 <?php public function test ( $ bool ) { if ( $ bool ) { return "OK" ; } else { return array () ; } } ?> この場合、戻り値で条件式に利用すると前項の暗黙の型変換と合わせると不具合のもとになります。 また、 PHP の組み込み関数では実行し失敗した場合にfalseを返す関数が多く、今まで使ってきた言語ではnullが返ってくることがほとんどだったので違和感があり、最初のころは間違えることが多かったです。 その他 bindValue()とbindParam()の違い bindValue()とbindParam()とはDBアクセス時に SQL にパラメータをバインドするための関数です。 bindValue() : 値をパラメータにバインドする プリペアド ステートメント で使用する SQL 文の中で、 対応する名前あるいは疑問符の プレースホルダ に値をバインドします。 bindParam() : 指定された変数名にパラメータをバインドする 準備された SQL ステートメント 中で、 対応する名前もしくは疑問符 プレースホルダ にパラメータをバインドします。 PDOStatement::bindValue() と異なり、 変数は参照としてバインドされ、PDOStatement::execute() がコールされたときのみ評価されます。 PHP の公式マニュアルには上記のように記載があります。 この二つの関数の大きな違いは、bindValue()は値に置き換えであり、bindParam()は参照変数に置き換わるということです。 例えば次の場合に問題が発生します。 <?php // 正常に実行される foreach ( $ array as $ key => $ value ) { $ stmt -> bindValue ( $ key , $ value ) ; } $ stmt -> execute () ; // すべてのKEYが$arrayの最後の$valueに置き換わる foreach ( $ array as $ key => $ value ) { $ stmt -> bindParam ( $ key , $ value ) ; } $ stmt -> execute () ; ?> bindValue()の場合は値が置き換わっているため問題なく実行できます。しかし、bindParam()を用いると参照変数に置き換わるため、参照している変数である$ value がループ中に中身が変わり意図しない値がバインドされてしまいます。 このため、通常バインドしたいときにはbindValue()を用いることで不具合は防ぐことができます。 まとめ PHP を使い始めて4ヶ月の間で戸惑ったことについてまとめました。 PHP にも少しづつなれてきましたが、まだまだ知らない仕様もたくさんあります。 今後は PHP の フレームワーク にも触れていきたいと考えています。 本記事がこれから PHP 学習する方の参考になれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、strongWhiteです。今回は大阪オフィスで開催された10月ビアバッシュをご紹介いたします。 前回の記事はこちら↓ tech-blog.rakus.co.jp はじめに 発表一覧 個人的に気になった発表 サービスの品質を考える 異文化間の開発で感じたこと my favorite UI おわりに 発表一覧 前回に引き続き、今回もオンラインでつないで東京オフィスのエンジニアと合同で開催することとなりました。 以下が今回の発表一覧です。多くの方に発表していただきました！ 自由枠（質疑応答込みで13分） サービスの品質を考える 異文化間の開発で感じたこと かみせんを通して見えたこと akkaでたこ焼きを焼く LT枠（5分厳守） my favorite UI 続・キャラ立ちのすゝめ コピペにする？共 通化 にする？それとも抽象化？ 初めての育休 全体に触れると長くなってしまうため、個人的に気になった発表をピックアップしてご紹介いたします。 個人的に気になった発表 サービスの品質を考える 「品質のよいサービスとは何か」に関するお話です。 ここで言う"品質"とは、弊社製品の利用形態である" クラウド サービス"においての品質です。 "品質がよい"とはすなわち"ユーザーに使われるもの（選んでもらえるもの）"であり、"ユーザーに使われるもの（選んでもらえるもの）"とはすなわち" 顧客満足度 が高いもの"ということになります。 品質には複数要素があり、当たり前品質・一元品質・魅力品質・ 無関心品質 、etc などさまざまです（この考え方を「狩野モデル」と言います）。 「ホテル予約」を扱う クラウド サービスなら、当たり前品質とは例えばログインできる、検索できるなど。魅力品質ならばホテルまでの移動ナビゲーション機能が付いているなどです。 上記は一例ですが、大事なのは"顧客にどのように響くかを考える"と言うこと。それこそがすなわち"品質のよいサービスを考える"と言うことになります。 この辺りはいわゆる上流工程で考え出され、 下流 工程を担当する開発者からは ブラックボックス になりがちですが、開発者目線でも、この要件（機能）が顧客にどんな価値を届けられるのかを意識することは大切だと思いました。 サービスの品質を考える information 狩野モデル - 日本科学技術連盟 異文化間の開発で感じたこと オフショアのエンジニアとの共同開発に関するお話です。 突然ですが弊社は ベトナム の ホーチミン に子会社が存在し、現地のエンジニアと共に開発を行っています。 弊社のように、海外に拠点を構えて共に仕事をしている会社は多いのではないでしょうか。そこで問題になるのが"文化の違い"です。 日本では「基本的に毎日定時までは業務に従事する」ことが普通だと考えますが、海を越えると「業務が一段落すれば、午後から全員有休を取る開発チーム」が存在する国もあるようです。 これはその国にとっての"常識"なので、何も悪くありません。 我々はよく自分たちの常識で物事を考えがちですが、異文化間で開発する以上、相手の文化の違いを理解しながら開発を進めることが必須です。 コミュニケーションに関しては「言わなくても伝わる」と考える文化と「言われないことは取り組まない」と考える文化、スケジュールに関しては「5年先を見据えてスケジュールを立てる」文化と「1日先だけスケジュールを立てる」文化などさまざま... 私も ベトナム のエンジニアとコミュニケーションを取る機会があるのですが、どうすれば自分の言いたいことが伝わるかや、自分の言ったことが不意に相手を傷つけていないかを常に考えるようにしています。 お互いを理解し合う心構えこそが重要ですね。 異文化間の開発で感じたこと information エリン・メイヤー (2015) 『 異文化理解力 - 相手と自分の真意がわかるビジネスパーソン必須の教養 』 英治出版 my favorite UI 発表者のお気に入りUI...ではなく、オシャレなUIが 裏目 に出てしまったお話です。 ここで言う"UI"はソフトウェアに限らず、街なかに溢れるさまざまなものを指します。 公共のゴミ箱や車止め、お店のドアなど、設計者は何か意図があってそのつくりにしているはずですが、ユーザは期待通りに使用してくれない場合があります。車止めの例だと、期待する使い方としては正に「車止め」なのですが、上面が平らな作りになっているためゴミ箱代わりに利用される...など。 車止めの例はまだ笑い話で済みそうですが、本来の使い方をされない（=想定外の使い方をしている）ことはソフトウェアの世界だと重大な不具合に繋がりかねません。 そうならないためにも開発時に入念なテストが重要ですね。 my favorite UI おわりに いかがでしたでしょうか。記事の中でご紹介できませんでしたが、今回は今年度入社された方と、 ベトナム のエンジニアによる自己紹介LTもあり、いつも以上に和気あいあいとした雰囲気になりました。 今後もビアバッシュの内容はブログという形でレポートしていきますので、どうぞお楽しみに！！

id:radiocat です。今回は、大阪オフィスでスタートした新しいイベントについてご紹介します。 rakus.connpass.com スタートの経緯 先月まで 「もくもく勉強会」 として自己学習メインの勉強会を開催していましたが、もう少し学びの要素を増やそうということで、LTを募集し、技術者同士の情報交換や交流を深める要素も追加して、今回から「Web× PHP TechCafe」として再スタートすることになりました。 ラク スの PHP 系のサービスのほとんどが大阪オフィスで開発していますので、 PHP という技術領域を支えつつ、我々自身も学びながら盛り上げていきたいと考えています。 会場の雰囲気 新たな試みということで、参加して頂けるだろうかという不安もありましたが、当初予定を増枠して20名を超えるかたに参加して頂き、LT枠も募集した3枠が全て埋まりました。ご参加頂いたみなさまありがとうございました！ なお、Web× PHP TechCafeを立ち上げるにあたっての経緯や運営陣の思いなどは別途記事にして Web × PHP TechCafe Advent Calendar 2019 - Qiita へ投稿する予定です。 LTセッション まずはLTセッションで登壇いただいた3つの発表内容をご紹介します。 なぜ PHP には Enum がないのか @miracle_fjsw さん speakerdeck.com Enum を標準仕様として採用するかどうか、過去に語られてきた議論について、 PHP コミュニティの メーリングリスト を追いかけてまとめた内容を紹介して頂きました。なぜか関西弁で翻訳された内容が、我々関西人にはよりリアルに伝わってきて「ここまで議論されてきたんならしゃーないな」とも思える内容でした。最後はワンチャンあるかもという Enum 待望派にとっては希望的な終わり方で締めて頂きました。 パーフェクト PHP のススメ @sakura_willow さん speakerdeck.com 言語仕様などの基礎知識から フレームワーク を使用したWebアプリケーション開発の深い知識までをカバーした書籍「パーフェクト PHP 」を紹介して頂きました。 MVC モデルやDB接続管理など、Webアプリケーション開発には必須の技術要素がどのような仕組みで成り立っているのかを完全に理解できる（した）ようです。まさに PHPer 必読書と言えます。 Laravel で Markdown をブラウザに表示する方法 @azuki_eater さん speakerdeck.com Markdown パーサ・ライブラリの cebe/ markdown を Laravel に導入する方法を紹介して頂きました。 github.com 当日の参加者の半分以上のかたが Lavavel を学習テーマにあげていたので、非常に注目度の高いテーマでした。コードを使った解説も実践向けで参考になりました。 ディスカッション・セッション LTの後は、一部の希望者で集まって「TechCafeをどんなコミュニティにしていくか？どんなことを勉強したいか？」についてディスカッションしました。様々な意見が出ましたが、その一部をご紹介します。 モブプロ 質問＋回答会 PHP クイズ大会 他のコミュニティとのコラボ PHP だけでなく周辺領域も含めた学習 設計ノウハウ コード精読会 読書会、おすすめの書籍紹介 思った以上に盛り上がって時間内に今後の方針をまとめることができませんでしたが、残りの検討は運営メンバーが引き継いで次回までに整理してテーマを絞ろうと検討中です。勉強したいテーマとしてあがっているものは、大きく2つの分野があります。 開発でつまづきがちなポイントを共有したり、分からないことを気軽に教え合えるような初心者向けテーマ 実践向けの課題やノウハウを共有したり、特定の技術テーマについて深堀りする経験者向けテーマ これらの分野からテーマを検討します。ご意見を頂いた皆さまありがとうございました。 なお、ディスカッション参加者以外のかたは自習をしたり、周囲の方々と情報交換するなどネットワーキングの場としても活用して頂きました。 TechCafeの雰囲気 その他の当日の様子についてご紹介します。まず、参加頂いたみなさんに、学習することや普段取り組んでいることなどのStudyテーマを共有していただきました。 Studyテーマ Laravelをテーマにあげているかたが多かったです。予想はしていましたが圧倒的な人気です。弊社のサービスでもLaravelを使っていますので一緒に学んでいきたいです。 PHP を勉強中、ちょっと使っている人が半数 参加者インタビューということで、「あなたの PHP 利用状況を教えてください」という質問をしてみました。結果は以下のとおりです。 PHP 利用状況 めっちゃ使ってる：3人 ちょっと使ってる：4人 勉強中：6人 はじめたい：1人 使わない：2人 当然ですが、学びの場なので勉強中のかたがたくさんいらっしゃいました。 緩やかな PHP 愛 次に、「あなたの PHP 愛を教えてください」という質問をしてみました。結果は以下のとおりです。 PHP 愛 NO PHP , NO LIFE：1人 好き。けど、無くても死なないかな。：6人 特に好きということもないが、嫌いということもない：6人 嫌い：0人 それ何？：2人 嫌いな人がいなくて少しホッとしました。 次回は 11/19 に開催します 早くも第2回を公開しています。既に増枠している状況ですので、興味のあるかたはお早めにご参加ください。 rakus.connpass.com なお、当日のテーマはconnpassに記載のSlackと参加者向けのメッセージでお知らせ予定です。ご参加お待ちしております。 【告知】 アドベントカレンダー をやります！ イベントを立ち上げた勢いで アドベントカレンダー まで立ち上げました！ qiita.com こちらはまだまだ枠が空いていますので、ぜひご参加お願いします。 PHP について今年学んだことをアウトプットして締めくくりましょう！

はじめに はじめまして。新卒1年目のtakaramです。 今回は、Gitのコミットで失敗した時に便利な「 git commit --amend 」コマンドをご紹介します。 目次 はじめに 目次 git commit --amend とは このコマンドでできること コミットメッセージの修正 コミット内容を後から追加 このコマンドでできないこと コミットからファイルを削除する 2つ以上前のコミットを修正する おわりに 　 git commit --amend とは その前に、そもそも amend という単語自体あまり耳慣れないかもしれません。辞書によれば、"amend"＝「修正する、改める」という意味です。 そして git commit --amend もまさに「 直前のコミットを修正する 」ためのコマンドなのです。 このコマンドでできること このコマンドで出来るのは、 コミットメッセージの修正 コミット内容を後から追加 の2点です。以下で実際の使い方を説明していきますが、その前に大事なことを。 今から紹介する方法を使っていいのは pushする前のコミットを修正したいときだけ です！ push済みのコミットを修正してしまうと、禁断のコマンド git push -f を使わざるを得なくなります。自分しか使わない個人 リポジトリ なら別ですが、そうでなければ別の方法を使ってください。 コミットメッセージの修正 コミットした後でコミットメッセージに誤字を発見したり、「もう少しわかりやすく書き直したいな」と思うこともあると思います。 そんなときは以下のようにします。 $ git add A $ git commit -m "誤字を含むコミット" [master (root-commit) 7033548] 誤字を含むコミット 1 file changed, 1 insertion(+) create mode 100644 A $ git log --oneline 7033548 (HEAD -> master) 誤字を含むコミット $ git commit --amend -m "修正されたコミット" [master 6fd014d] 修正されたコミット Date: Fri Nov 8 17:00:03 2019 +0900 1 file changed, 1 insertion(+) create mode 100644 A $ git log --oneline 6fd014d (HEAD -> master) 修正されたコミット git commit --amend を実行した後では「誤字を含むコミット」がなくなり、「修正されたコミット」だけになっています。 -m オプションを付けない場合、修正前のコミットメッセージが入力された状態のエディタが開きます。 長いメッセージの一部だけを修正する場合はこちらの方が便利ですね。 コミット内容を後から追加 コミット後に追加で修正を行った git add し忘れたファイルがあった 一時コミットを残したくない といった時にも git commit --amend が活躍します。 以下は「ファイルA、Bを修正したが、Aを git add し忘れた」といった場合の例です。 $ git add B $ git commit -m "AとBを修正" [master db4514a] AとBを修正 1 file changed, 1 insertion(+) $ git status ブランチ master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: A no changes added to commit (use "git add" and/or "git commit -a") $ git add A $ git commit --amend --no-edit [master 0469077] AとBを修正 Date: Fri Nov 8 17:31:15 2019 +0900 2 files changed, 2 insertions(+), 1 deletion(-) この例では、 --no-edit オプションを使い前回のコミットメッセージのままコミットしています。このオプションを外せば前節と同様コミットメッセージの変更も可能です。 このコマンドでできないこと コミットからファイルを削除する コミットに追加することはできますが、既にコミットに含まれた修正を外すことはできません。これがしたい場合は git reset を使うことになります。 ※ git reset については こちらの記事 をご覧ください 2つ以上前のコミットを修正する あくまで直前のコミットを修正するコマンドなので、これ単独では2つ以上前のコミットは修正できません。これがしたい場合は git rebase -i と組み合わせて使います。 おわりに 直前のコミットの内容を修正できる git commit --amend の紹介でした。 念のためもう一度言いますが、これは push前のコミットに対してのみ 使うようにしてください。既にpushしてしまった場合は新しいコミットを作りましょう。 コミットメッセージの修正は諦めてください。 今回紹介した内容は、最低限のGit操作には必須ではないものの、やはりコミット履歴もできればキレイにしておきたいものです。今まで git commit --amend を使ったことがなかった方はぜひ活用してみてください！ 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

y_kwmtです。11/2に弊社がスポンサーとなっている、FRONTEND CONFERENCE 2019に登壇してきました。 イベント概要 日時：2019年11月2日 会場： グランフロント大阪 公式HP： https://2019.kfug.jp/ 私の発表は11:45からでした。（2番目） 発表資料 speakerdeck.com 今回は自分の過去の経験をもとに資料を作成しました。 Vue.jsを知らない人に伝わりやすい資料を作成することに苦労しました。 感想 初めての技術イベント登壇で、なおかつ発表経験が少ないので、無謀な挑戦だったと思いましたが、無事発表することができました。 多くの方に聞いていただけてとても嬉しかったです。 今回の登壇に協力してくださった方々には大変感謝しております。今後も学習したことをブログや登壇でアウトプットしていきたいと思います。 また、自分の発表以外の時間に、他の登壇者の発表を聞いたり、ハンズオンに参加したりしました。 話す側としても、聞く側としてもかなり充実したイベントでした。

はじめに こんにちは。新卒2年目のEngawaです。 今回はGASを用いてサーバーレスでLINEbotを作成しましたので紹介してきます。 はじめに GAS(Google Apps Script)とは bot作成 新規チャンネルの作成と設定 GAS作成 URLの発行 発行したURLの設定 実行 おわりに 参考 GAS( Google Apps Script)とは Google が提供しているプログラミング環境のことです。 スクリプト の言語は、 JavaScript をベースとしています。 GASについては以前このブログで分かりやすく書いている記事があるのでご覧ください。 tech-blog.rakus.co.jp bot 作成 新規チャンネルの作成と設定 はじめに LINE Developers を使用して新規チャンネルを作成していきます。 LINE Developersにアクセス後Lineのアカウントでログイン > 新規プロバイダーの作成 > 新規チャンネルの作成の流れで進めてください。 新規チャンネルの作成時、　 LINEログイン 、 Messaging API 、 Clovaスキル のいずれかを選択する画面が表示されますが、 Messaging API を選択してください。あとは必須箇所を適当に埋めて同意すれば作成完了です。 作成完了後、作成したチャンネルを選択し、チャンネル基本設定の画面を下にスクロールすると アクセストークン の項目があるので 再発行 ボタンを押してアクセス トーク ンを発行しておいてください。GAS と紐づける際に必要になります。 さらに下にスクロールすると 自動応答メッセージ の項目があるので 設定はこちら のリンクをクリックして応答設定画面を開いてください。 詳細設定に 応答メッセージ と Webhook の項目があるので、 応答メッセージ：オフ Webhook：オン で設定してください。 設定変更後は画面を閉じて、作成したチャンネルのチャンネル基本設定の画面を更新してください。 GAS作成 以下を スクリプト エディタに記載します。 ACCESS _TOKEN部分には上記で発行したアクセス トーク ンを記入してください。 // アクセストークン var ACCESS_TOKEN = '' // メッセージが送付された際に、実行される関数 function doPost(e){ var replyToken = JSON.parse(e.postData.contents).events[0].replyToken; var userMessage = JSON.parse(e.postData.contents).events[0].message.text; var url = 'https://api.line.me/v2/bot/message/reply'; var headers = { 'Content-Type': 'application/json; charset=UTF-8' , 'Authorization': 'Bearer ' +ACCESS_TOKEN }; var payload = JSON.stringify({ //メッセージ送信内容 'replyToken': replyToken , 'messages': [{ 'type': 'text' , 'text': userMessage }] } ) var options = { 'headers' : headers , 'method' : 'post' , 'payload' : payload }; // メッセージを応答 UrlFetchApp.fetch(url ,options) } URLの発行 作成した スクリプト にアクセスできるように設定します。下記手順で実施してください。 ・ 公開 > ウェブアプリケーション として導入 ・ Execute the app as：me ・ Who has access to the app：Anyone,even anonymous(全員(匿名ユーザを含む)) ・Deplyボタンを押下するとURLが作成されます。 発行したURLの設定 作成したチャンネルを選択し、チャンネル基本設定の画面を下にスクロールすると Webhook送信 と Webhook URL ※SSLのみ対応 の項目があるので、 Webhook送信：利用する Webhook URL ※ SSL のみ対応：発行したURL をそれぞれ設定します。 これで作成と設定は完了です。 実行 bot 作成が完了したのであとは実行です。 チャンネル基本設定に LINEアプリへのQRコード があるので読み取って登録してください。 あとはLINE上で適当な文字を打ち込めば、打ち込んだメッセージを返してくれます。 今回は入力した文字列をそのまま返すようになっているのですが、特定の文字が打ち込まれた時に返すメッセージを指定するには スクリプト の一部を以下のように変更すれば可能です。 var reply = null; if(userMessage === 'おはよう'){ reply = 'ございます'; }else{ reply='さようなら'; } var payload = JSON.stringify({ //メッセージ送信内容 'replyToken': replyToken , 'messages': [{ 'type': 'text' , 'text': reply //ここを変えると送信するメッセージを変更できる }] } ) おわりに 今回はサーバーレスでLINEbotを作成しました。 API を用いて天気予報や電車遅延情報を取得し、返答メッセージとして設定しておくことで確認することもできます。 参考 tech-blog.rakus.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに こんにちは。新卒２年目のtaku_76です。 前回記事 では、FirebaseのRealtime Databaseを利用してリアルタイムチャットを作成しましたが、 その他にも様々な機能があるということで今回はFirebase Authenticationを使ってログイン機能を実装してみましたので紹介します。 はじめに Firebase Authenticationとは 実装 Firebaseでプロジェクトの作成 ログイン方法の設定 ユーザーを新規登録する ログイン処理を行う おわりに 参考 Firebase Authenticationとは Firebase Authenticationはほとんどのアプリで必要となるユーザー認証を簡単に実装することができます。具体的にはパスワード認証や、 Google 、 Facebook 、 Twitter などのフェデレーションIDプロバイダを使用した認証を行うことができます。方法としては、 FirebaseUI を使用するか、Firebase Authentication SDK を使ってログイン方法を手動でアプリに統合することで、ユーザーをFirebaseアプリにログインさせることができます。今回はメールアドレスとパスワードを用いてユーザー認証機能を実装します。 実装 Firebaseでプロジェクトの作成 以下にアクセスしてプロジェクトを作成します。 https://firebase.google.com プロジェクトが作成できたらウェブアプリにFirebaseを追加します。 scriptタグが表示されるので、今回作成するファイルapplication.jsに貼り付けます。 ログイン方法の設定 ログイン方法はメール / パスワードを有効にしておきます。 index.htmlにdivタグを追加しておきます。 <div> メールアドレス<input id="mailAddress" type="mailAddress" required/> </div> <div> パスワード<input id="password" type="password" required/> </div> <button id="login">ログイン</button> <button id="register">新規登録</button> ユーザーを新規登録する createUserWithEmailAndPassword メソッドにmailAddressとpasswordを渡すことでユーザーの新規登録ができます。 //新規登録処理 register.addEventListener('click', function(e) { var mailAddress = document.getElementById('mailAddress').value; var password = document.getElementById('password').value; firebase.auth().createUserWithEmailAndPassword(mailAddress, password) .catch(function(error) { alert('登録できません（' + error.message + '）'); }); }); メールアドレスとパスワードを入力して新規登録ボタンを押します。 すると以下のようにfirebaseの画面ではユーザーが登録されていることがわかります。 ログイン処理を行う signInWithEmailAndPasswordメソッドにmailAddressとpasswordを渡すことでログイン処理ができます。 //ログイン処理 login.addEventListener('click', function(e) { var mailAddress = document.getElementById('mailAddress').value; var password = document.getElementById('password').value; firebase.auth().signInWithEmailAndPassword(mailAddress, password) .catch(function(error) { alert('ログインできません（' + error.message + '）'); }); }); そしてonAuthStateChanged メソッドを使用して正常にログインができているか判定します。正常にログインできていれば、ユーザーに関する情報を取得できます。今回はログインできたことだけを確認するためにalertでメッセージを出す以外の処理は行なっていません。 //認証状態の確認 firebase.auth().onAuthStateChanged(function(user) { if(user) { //ログイン状態 alert("ログインに成功しました"); }else{ //ログアウト状態 } }); これで先ほど追加したユーザー情報を入力してログインを行うと以下のようになります。 ちなみに存在しないユーザーでログインすると以下のようなエラーが出ます。 これでユーザーを新規登録してログインするまでの処理は完了しました。 今回は実装を行なっていませんが、ログアウトについてはsignOutメソッドを使用することによって実装できます。 おわりに Firebase Authenticationを使ってユーザー認証を実装しましたがかなり手軽に実装できました。 今回はメールアドレスとパスワードを使用した認証でしたが、その他の認証も簡単に実装できるとのことなので試していきたいと思います。 参考 www.topgate.co.jp firebase.google.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、新卒2年目のyk_itgです。 業務の中で内容が同じ大量のテストデータが必要なテストがあったのですが、手作業で作成するとたくさんの手順を踏まなくてはならなかったり、入力を間違えたりして大変なので、なんとか SQL でできないか考えてみました。 はじめに 例えばこんなデータ 複製する 1. コピーしたいデータをtmpテーブルにコピーする 2. 変更したい部分のみを書き換える 3. 編集したデータを元のテーブルに挿入する 実行結果 関数にしてみる 実行結果 終わりに 例えばこんなデータ 例えばこのような感じのデータがあったとします。 CREATE TABLE chohyo ( chohyo_id INTEGER PRIMARY KEY, status INTEGER , user_name TEXT, title TEXT, hoge_flag INTEGER , total_price INTEGER ); CREATE SEQUENCE chohyo_sequence; CREATE TABLE chohyo_meisai ( chohyo_id INTEGER , meisai_number INTEGER , hoge_name TEXT, price INTEGER , PRIMARY KEY(chohyo_id, meisai_number), FOREIGN KEY(chohyo_id) references chohyo (chohyo_id) on delete cascade ); chohyo と chohyo_meisai は1：多の関係で、chohyoを作成する毎にシーケンスによってidに値が割り振られていくイメージです。 postgres=# SELECT * FROM chohyo WHERE chohyo_id = 1 ; -[ RECORD 1 ] ------------ chohyo_id | 1 status | 0 user_name | taro title | テスト帳票 1 hoge_flag | 0 total_price | 1000 postgres=# SELECT * FROM chohyo_meisai WHERE chohyo_id = 1 ; -[ RECORD 1 ]-+ --------- chohyo_id | 1 meisai_number | 0 hoge_name | コーヒー price | 500 -[ RECORD 2 ]-+ --------- chohyo_id | 1 meisai_number | 1 hoge_name | パン price | 500 今回はこのデータを複製する方法を考えていきます。 複製する SQL でテスト用のダミーデータを作成する方法としては作成したいデータの値を入れたINSERT文を作る、COPYを使う方法等ありますが、それぞれカラムを追加したときに対応する必要があったり、ファイルを操作する必要があったりで面倒です。 なるべくデータベース内で完結してほしいので、以下の手順で複製していきます。 コピーしたいデータをtmpテーブルにコピーする 変更したい部分のみを書き換える 編集したデータを元のテーブルに挿入する 1. コピーしたいデータをtmpテーブルにコピーする CREATE TABLE AS 文 *1 を使って、コピーするデータをtmpテーブルにコピーします。 TEMPORARY を指定するとセッションが切れたときにtmpテーブルは削除されるので、不要なデータが残る心配が無くなります。 下の SQL を実行する前に \set id 1 や psql -v id=1 などでコピーしたいデータを指定しておいてください。 CREATE TEMPORARY TABLE tmp_chohyo AS SELECT * FROM chohyo WHERE chohyo_id = :id; CREATE TEMPORARY TABLE tmp_chohyo_meisai AS SELECT * FROM chohyo_meisai WHERE chohyo_id = :id; 2. 変更したい部分のみを書き換える tmpテーブルにデータをコピーできたので、次は加工します。 下の SQL では chohyo の status 以外はそのままにして、 chohyo_id をシーケンスによって採番しています。 UPDATE tmp_chohyo SET chohyo_id = nextval( ' chohyo_sequence ' ), status = 1 ; UPDATE tmp_chohyo_meisai SET chohyo_id = ( SELECT chohyo_id FROM tmp_chohyo); 3. 編集したデータを元のテーブルに挿入する あとは加工したデータを元のテーブルに挿入するだけです。 INSERT INTO chohyo SELECT * FROM tmp_chohyo; INSERT INTO chohyo_meisai SELECT * FROM tmp_chohyo_meisai; 実行結果 postgres=# SELECT COUNT (*) FROM chohyo WHERE user_name = ' taro ' ; -[ RECORD 1 ] count | 2 関数にしてみる 上の SQL ではデータごとに1回実行しなくてはならず面倒なので、 PL/pgSQL *2 の関数にしてみます。 長くなりそうなので説明は省きますが、このような感じになります。 CREATE OR REPLACE FUNCTION copy_chohyo(chohyoId integer , count integer ) RETURNS VOID AS $$ DECLARE recordCount integer ; nextId integer ; resultChohyoCount integer ; resultMeisaiCount integer ; BEGIN SELECT COUNT (*) FROM chohyo WHERE chohyo_id = chohyoId INTO recordCount; RAISE NOTICE ' 件数 = % ' , recordCount; IF recordCount <> 1 THEN RETURN ; END IF ; -- テーブル構造をコピー CREATE TEMPORARY TABLE tmp_chohyo AS SELECT * FROM chohyo WHERE false ; CREATE TEMPORARY TABLE tmp_chohyo_meisai AS SELECT * FROM chohyo_meisai WHERE false ; -- コピーする数だけtmpにコピー&加工 FOR i IN 1 .. count LOOP INSERT INTO tmp_chohyo SELECT * FROM chohyo WHERE chohyo_id = chohyoId; INSERT INTO tmp_chohyo_meisai SELECT * FROM chohyo_meisai WHERE chohyo_id = chohyoId; -- あらかじめ次の値を保存 SELECT nextval( ' chohyo_sequence ' ) AS next_id INTO nextId; UPDATE tmp_chohyo SET chohyo_id = nextId WHERE chohyo_id = chohyoId; UPDATE tmp_chohyo_meisai SET chohyo_id = nextId WHERE chohyo_id = chohyoId; END LOOP ; -- コピーデータを挿入 INSERT INTO chohyo SELECT * FROM tmp_chohyo; GET DIAGNOSTICS resultChohyoCount = ROW_COUNT; RAISE NOTICE ' chohyo の挿入件数 = % ' , resultChohyoCount; INSERT INTO chohyo_meisai SELECT * FROM tmp_chohyo_meisai; GET DIAGNOSTICS resultMeisaiCount = ROW_COUNT; RAISE NOTICE ' chohyo_meisai の挿入件数 = % ' , resultMeisaiCount; -- 完了後処理 DROP TABLE tmp_chohyo; DROP TABLE tmp_chohyo_meisai; RETURN ; END ; $$ LANGUAGE plpgsql; 実行結果 postgres=# SELECT copy_chohyo( 1 , 5 ); NOTICE: 件数 = 1 NOTICE: chohyo の挿入件数 = 5 NOTICE: chohyo_meisai の挿入件数 = 10 -[ RECORD 1 ]- copy_chohyo | postgres=# SELECT COUNT (*) FROM chohyo WHERE user_name = ' taro ' ; -[ RECORD 1 ] count | 6 終わりに 今回は SQL のみでシーケンス採番付きのテストデータを複製する方法を考えてみましたが、いかがでしたでしょうか。 テストでデータを複製する際の参考になれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : https://www.postgresql.jp/document/10/html/sql-createtableas.html *2 : https://www.postgresql.jp/document/9.4/html/plpgsql.html

はじめに こんにちは、aa_cryingです。 早いもので入社から1年半が経ちました。 はじめに kindle unlimitedとは 脱初心者のJavaScript力を底上げするための本 「巻き上げ」とは おわりに kindle unlimitedとは kindle unlimitedとは、 Amazon が展開する、月額制の 電子書籍 読み放題サービスです。 なんと今なら 30日間無料 で様々な書籍・漫画が読めるので、 JavaScript の技術書籍を探してみました。 脱初心者の JavaScript 力を底上げするための本 Amazon で「 JavaScript 脱初心者」と検索すると検索結果の一番上に出てくる書籍です。 脱初心者のJavaScript力を底上げするための本／天田士郎 こちらの書籍では、1章は基本的なコーディングテクニック等が記載されていますが、 2章以降では無名関数・即時関数の使い方や、巻き上げ等 脱初心者 に必要な知識が説明されています。 コードとともに説明されているため、実際に動きを確かめながら進めることが出来ます。 私は JavaScript 特有の「巻き上げ」という概念を知らず、この書籍を読んで初めて知りましたので、抜粋して紹介させていただきます。 「巻き上げ」とは 以下は「巻き上げ」が起こるコードの例になります。 var a = 'hoge' ; var f = function () { console.log(a); var a = 'fuga' ; console.log(a); } f(); この例では、一見すると1回目のconsole.log(a)では 「 hoge 」 が出力されそうですが、 「undefined」 になります。 JavaScript では、関数内のどの位置でもvar文を利用して変数の宣言ができます。 しかし、これらの変数は関数内のいかなる場所で宣言されたとしても「この関数の先頭で宣言された」とみなされます。 このため、以下の例と同じになります。 var a = 'hoge' ; var f = function () { var a; console.log(a); a = 'fuga' ; console.log(a); } f(); aは1回目のconsole.log(a)の時点では新たに宣言だけされており、代入までは行われません。 (巻き上げられるのは宣言部分のみ) ですので、1回目のconsole.log(a)の時点では 「undefined」 となるのです。 このように、他の JavaScript 特有の規則等についても例を交えてわかりやすく説明されており、 脱初心者 には非常に為になる書籍でした。 おわりに 今回は kindle unlimitedで無料で読める JavaScript の脱初心者本について紹介させていただきました。 技術書籍を読みたいけれど何から読んだらよいかわからない 本屋で探すのが面倒 という方は、 kindle unlimitedで探してみるのもアリかもしれません。 他にも読んでみた書籍がありますので、そちらは次の機会に紹介させていただければと思います。

はじめに こんにちは、新卒のcrowd_kです。 今年の4月に入社をし、社会人になって約半年が経ちました。 入社するまでプログラミング未経験者だったので、日々の業務で新しい知識や様々な発見の連続に翻弄されながら、でもどこかで楽しみつつ学習をする毎日を過ごしています。 その中で1つ気になったことがありました。 それは、プログラム内のインデントを、タブ文字(\t)ではなくスペースで作成する方針になっていたことです。 プログラミング歴の浅い私は全く意識せず、使用している Eclipse の初期設定であるタブを用いていました。なので改行等をすると、作成されるインデントはタブで構成されていることになります。 しかし、コードのレビューを依頼した際に上記の方針(インデントはスペースで作成する)に引っ掛かり、コード内のタブをすべてスペースに置き換えるという作業を行いました。 最初はなにも疑わずに修正していましたが、後々考えてみるとなぜなんだろうと疑問を持ちました。 「タブを用いることで生じるバグなどがあったりするのか？」 考えてみても答えは出ないので、調べてみることにしました。 インデント そもそもプログラミングにおけるインデントとは、一般的に 「 プログラムのネスト構造を読み手にわかりやすく表現するために行頭の位置を変化させること 」 だと思います。 if (a == b){ if (b == c){ System.out.println( "aとbとcは全て同じ" ); } System.out.println( "aとbは同じ" ); } else { if (b != c){ System.out.println( "ｂとｃは同じ" ); } System.out.println( "aとbは同じではない" ); } 上のコードのように行頭をそろえたほうが見やすくなります。プログラミング経験者なら誰でも行ったことがあるかと思います。 このインデントを作るための空欄を表現するためにタブを使っていたところ、「スペースに直せ」とはじかれたわけです。 調べてみると、「インデントをタブで行う人派」(以後タブ派)と「インデントをスペースで行う人派」(以後スペース派)で分かれよく論争が起きる、答えのない有名な議題の1つだということがわかりました。 以下に調べた結果をまとめていこうと思います。 タブ・スペース、それぞれの違い 結論から言うと タブを使用した結果、何かの不具合やバグが発生するなどといったデメリットは、ほぼ発生しないようです。 しかし、環境によってタブが半角スペース×4、または×２になってしまったり、単なる半角スペースに置換されてしまったりなどインデントの幅が変化し、見た目が変わってしまう事があるらしく、「ほぼ発生しない」という表現にしました。（逆に見た目を変化せることができるということです） この、環境によって見た目が変わってしまう、または変えることができる特徴こそが、この論争の重要なポイントのようです。 流行りの歴史 まず最初に流行ったのは「タブ」だったそうです。 理由は単純でスペースでインデントを作るには、そのキーを何回も押すのが面倒な点と、文字数を減らすことができるのでファイルサイズも抑えることができる点、この2点が挙げられます。 しかし、先に述べたデメリットが発覚したことで、回避するためにスペース×４でインデントを作るのが主流になりました。 また、そこから派生してスペース×2をインデントとする人たちも現れたようです。これは、インデントの幅が大きくなった時、スペースの個数を間違えることが多く、その問題を改善するためにインデントに使うスペース数を減らした結果だそうです。 それぞれの長所短所を簡単にまとめると以下のようになります。 　 タブ スペース メリット　 入力回数が少ない ファイルサイズを抑えることができる エディターによって自由にインデントの幅を設定することができる どの環境でも同じ見た目にすることができる (環境に依存しない) デメリット 環境によって見た目が変化する 打ち込む回数が多く手間になる 打ち込む回数にミスが生じた場合、見た目が悪くなる 上に記した歴史は、あくまで流行りでありどの時代でもタブ派とスペース派は混在し、どちらを使うのが良いかという論争を繰り広げてきました。 両者にはそれぞれ長所と短所があるため、いつになってもこの論争は終わらないのです。 それぞれの派閥のエンジニアの意見を見ると以下のような意見がみられました。 タブ派 ・ エディタ等の設定を変更すれば好きなように幅を変化っさせることができるので、相手にとって一番見やすい形に都度変更してもらうことができる ・ タブのほうが操作が簡単であり、事実上タブによるデメリットはないので効率を考えるとタブを使うべき ・スペースの数をそろえるのが面倒 ・ インデントの幅が正しいのかを簡単に見分けることができる 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...etc スペース派 ・ コードを綺麗に見せるには自分が意図した通りに表示させる必要がある ・ 環境によって表示が変わってしまうのでは、相手に自分の伝えたいことが伝わらないかもしれない ・ エンジニアならファイルサイズが小さくなるメリットより見やすさを重視すべき ・ 全角スペースを探すために非表示文字を表示させる際に、スペース・タブが混在していると探すのが大変 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...etc コーディングのセンス次第 私は、両者の様々な意見をみて書き手の性質によるのではないかなと感じました。 コードを何かの芸術作品に例えて考えると、 自分が作り上げた作品を自分が一番綺麗だと思う見せ方で見せたいから、作品の置き方、見る角度、照明等をすべて指定するのがスペース派 作品を見せる際の照明等のこだわりはなく、見る人が一番だと思う方法で見てもらえるのが一番だと考えるのがタブ派 のどちらが良いかという話になるんじゃないかなと思います。 どちらも読み手にいかにプログラムコードを綺麗に見せるかに重点が置いてあり、それぞれがいいと思うものを使うのが一番かなと思いました。 しかし、1点だけ注意しなければならないことが。 複数人で開発を行う場合、それぞれが好みのインデントのルールで開発を行うと見た目がぐちゃぐちゃになり、非常に見づらいコードになってしまいます。 なので、その際はプロジェクトのルールに従う必要があります。(言うまでもないかもしれませんが...) これを考えると、現在はスペース派が多数派になっているので、こだわりがないのならスペースに慣れたほうがいいかもしれません。 終わりに 調べた結果、タブを使用してもバグ等の原因になりえないことがわかりましたが、コーディングに関して深い理由があるんだなということに気づけました。 また、気になったことを記事にしていこうかなと思います。

こんにちは。west-c です。 書籍「エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする」を読み、個人的に刺さる内容でしたので、今回はこちらの本を紹介します。 エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ) 作者: 西尾 泰和 発売日: 2018/08/10 メディア: 単行本（ソフトカバー） なお、先日社内で開催されたビアバッシュでもこの書籍の紹介を行いました。 tech-blog.rakus.co.jp 以下のような方におすすめの書籍です 勉強しなくては思うが勉強の仕方が分からない やる気が起きない・維持できない そもそも何から勉強すれば良いのか分からない 私はまさに上記のような悩みを持っていました。 若手の方を中心に、自己研鑽のための学習方法に悩んでいる方におすすめします。 「知的生産」とは 知的生産とは『 知識を用いて価値を生み出すこと 』と書籍内では定義されています。 例えばプログラムを作成したり執筆を行い書籍を出版したりする等、インプットした知識をもとに新たな価値を生み出すことが知的生産にあたります。 その中でも、どのように学習するか、言い換えるとどのように知識をインプットし自身の中に定着させるかについての記述が特にためになる書籍でした。 学びのサイクル 学習は「情報収集」「モデル化」「検証」の3要素を繰り返すことで成り立っていると書かれています。 情報収集：知識をインプットするフェーズ モデル化：情報収集した知識を整理するフェーズ 検証：アウトプットを通じてモデル化した知識が正しく理解できているか確認するフェーズ 自身の今までの学習方法を振り返ると、情報収集は行うものの知識を腹落ちさせるためのモデル化および検証のフェーズが足りていませんでした。 書籍などを読んでも自分の知識として定着していない感覚があったのも、この学習のサイクルを回すことができていなかったためだと感じました。 また、「情報収集は自分の知りたいと思うところからつまみ食いするような学習方法でも良い」との記述が書籍内でありました。 私の場合、書籍を読む際には最初から最後のページまで読まなければならないという先入観があり、結果として最後までやる気を維持できず投げ出してしまうことも多々あったため新たな発見でした。 学びのサイクルを実践してみる 早速実践しなくては読んだ意味が無いということで、『「エンジニアの知的生産術」を読み学びのエッセンスを習得する』という学習を、学びのサイクルに当てはめて実践してみました。 1. 情報収集 今回は書籍を読むことがこのフェーズにあたります。 私は Kindle 版で読んでいたため、印象的な文章は適宜ハイライトを付けながら読み進めました。 2. モデル化 書籍から学んだ内容を整理するフェーズです。ここでは、考えをまとめる方法として書籍内で紹介されていた「書き出し法」「 KJ法 」を利用して整理を行いました。 ①得た情報を書き出す ハイライトを付けた内容を中心に、書籍から得た情報を付箋に書き出しました。 書籍内だけに限らず、別の書籍の関連する部分 *1 や自身が感じたことについても同様に書き出しています。 ②分類する 書き出した付箋を、関連するもの同士グループ化し、そのグループを表す表札を付けます。 ここでは、「この記述はどの章にあった」ということを忘れて、付箋同士を眺めて新たな関連を見つけることを意識しました。 ③図解化する 分類した単位で付箋を展開し、各付箋の繋がりを図示していきます。 この図示した内容をもとに、社内のビアバッシュで紹介を行うためのスライドを作成しました。 3. 検証 社内のビアバッシュにて紹介を行い、伝えたいことが伝わっているかの検証を行いました。 若手メンバーを中心にためになったという感想をいただいたので、自身が書籍を読んだときに感じた気持ちが多少なりとも伝わったのではないかと思います。 また、本記事による文章化は二度目の検証という意味合いもあります。 実践してみて スライドの作成中、理解が曖昧な箇所に気付き再度本を読み返すことがありました。 モデル化・検証により分かったつもりで実は理解できていなかった点に気付くことができたことから、復習として有効であり、また得た知識も自身の中に定着しているように感じました。 加えて、モデル化の過程でフラットな階層で得た情報を一覧化したことで、別の章に記載されている事同士の関連に気付き新たな発見があった点も収穫でした。 一方で以下のような壁にもぶつかり、書き出し法・ KJ法 の難しさを痛感しました。 KJ法 は付箋100枚程度からが有効、との記述が書籍内であったが100枚書き出すのはなかなか難しい *2 付箋の分類は意識しても章単位にまとまってしまいがち スライド作成の段階で話の進め方に悩み、付箋の繋がりをきちんと図解化できていないことが露呈する 上記のような難しさは感じましたが、考えを整理する方法として手応えは感じましたので今後も実践して感覚を掴めればと思います。 感想 タイトルに「エンジニアの」とあり例示こそエンジニア向けですが、多くの人にとって有用な学習方法のエッセンスが含まれている一冊でした。 書籍を通じて学習に対するモチベーションが生まれたので、モチベーション維持の方法など学んだ知識を取り入れながら積極的に情報収集を行っていきたいと思います。 また、情報収集だけではなく、自身の中に知識を腹落ちさせるモデル化・検証のフェーズも疎かにせず学習に取り組んでいきたいです。 関連リンク エンジニアの知的生産術 著者公式ページ - 西尾泰和のScrapbox 著者による公式ページです。目次や「はじめに」ページを読むことができます。 *1 : 例えば書籍内の「卓越」の話は、「達人 プログラマー 」の「知識の ポートフォリオ 」の話と通じると感じました *2 : 読了後にまとめて書き出したことで忘れてしまった内容もあると感じるため、読みながら感じた点を都度付箋に書き出していけば100枚ほどになるのかもしれません

こんにちは。新卒1年目エンジニアのrs_shoです。投稿は2回目になります。 今回はGitのブランチの切り替えで失敗したことについて書いていきたいと思います。 はじめに なぜ自動マージが起こったのか 解決方法 stashの戻し方と、それ以外の対処法 おわりに 参考資料 はじめに 前回の記事で commitのタイミングと注意点について の記事を書きましたが、それに少し近い内容です。 別のブランチでコード書いてたけど、元のコードのバグ修正依頼が来たり、レビュー後差戻しがあった場合は、 当然その修正した内容のブランチに切り替えますよね。 その時に元のブランチで書いていた内容が切り替え先のブランチに自動マージされ、余計なファイルとしてstatusに出てきた！なんて経験ありませんか？ 僕はそれで色々と困ったので、その時に使った解決策を簡単に説明します。 なぜ自動マージが起こったのか まず、僕が経験した自動マージされてしまった原因ですが、 元のブランチでの作業内容をcommitしていなかった その状態でブランチを切り替えた際に切り替え先でコンフリクトが発生しなかったため、自動マージされてしまった なぜcommitしてなかったかというと、修正途中の段階でcommitしたくなかったからですよ？忘れてませんよ？ 僕はその時、なぜマージしてないのに切り替え前のブランチから作業中のファイルがマージされていたのかわからず、困りました。 そして、切り替え先の修正後、元の作業中のブランチに戻ろうとしたらcommitしてくださいと出てしまう。戻れないじゃん・・・ 解決方法 この問題の解決方法ですが、僕は根本的な解決はしてなくて、ちょっと無茶苦茶なことをしているかもしれませんがご了承ください。 僕はそのブランチから自動マージされた内容を消そうかと考えました。 でも切り替え前のブランチから修正内容が消えたらすごく嫌ですよね・・・ commitのタイミングと注意点について で、 機能に関わりのない個人設定のファイル や 間違って編集したファイル は commit対象にするべきではないということを説明しました。 かといってcommitしなきゃブランチ切り替えられないんじゃどうしようもないじゃん！ そこで、色々探していった結果、stashコマンドにたどり着きました。 $ git stash これを打つだけ。何をしているのかちょっと説明しますね。 ・コミットはせずに変更を退避したいとき、stashコマンドを使用すると、コミットしていない変更を退避することができる ・退避させていた変更を後で戻して作業を再開することもできる stashはcommitの記録に残るものではなく commitしていない変更内容を退避する コマンドなので、 「変更内容はひとまず置いといて・・・」ができちゃいます。Gitってなんて便利なんだろう。 stashコマンドのおかげで、commitしてくださいと怒られずにブランチ切り替えができました。 stashの戻し方と、それ以外の対処法 僕は心配性なので、変更先で消えるのを怖がっていました。(頑張ったのに消えちゃうとつらい) stashを戻す方法と、それ以外の対処方法を記載します。 まずはstashを戻す方法から。stashって使ったタイミングでcommitみたいに履歴として残ります。 stashした履歴から指定の場所に戻りたい場合は、 $ git stash list stash@{0}: WIP on [ブランチ名]: [HEADのcommitハッシュとcommitメッセージ] stash@{1}: WIP on [ブランチ名]: [HEADのcommitハッシュとcommitメッセージ] で git log のcommit履歴みたいにstashの履歴と大まかな内容が見れます。 そこから番号を指定して $ git stash apply stash@{0} ←0は{ }の番号 これで任意のstashの部分の変更が戻ります。 その他に最新のstashの履歴を戻したい場合には # 最新の退避内容を復元して、退避したデータを消す際(戻した後stashの履歴から削除する) $ git stash pop # 最新の退避内容を復元して、退避したデータを残す際(戻した後stashの履歴から消さずに残す) $ git stash apply stashの番号などを指定しなければ最新が戻ります。 僕は履歴残しても戻したらもう使わないと思ったのでpopを使いました。 最後に、変更自体をなかったことにするコマンドです。僕が使うのを怖がったコマンドです。 別に特殊なことはしませんし、問題が起こることはないと思います。 (何か起きても僕のせいにしないでください) 変更をなかったことにするには # 指定したファイルの変更をなかったことにする $ git checkout [ファイル名] もしくは # statusに出ているすべての変更をなかったことにする $ git checkout . というコマンドです。最近必要ないファイルをadd、commitしないようにするときにも使ってます。 おわりに 以上、ブランチ切り替えで困った際の対処法などをまとめてみました。 自動マージで困った方、編集したファイルの退避の仕方の参考になれば幸いです。 参考資料 git stash で、作業中の変更をいったん横に退けておく 【git stash】コミットはせずに変更を退避したいとき エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

初めまして。今年度新卒入社の mako _makokです。最近実家に帰って水族館でペンギンを見てきました。 今回は 全文検索エンジン のコア機能の一つであるAnalyzerについて書いていきたいと思います。 はじめに 検索エンジンの仕組み Analyzerとは 前準備 Char filter Tokenizer Token filter おわりに はじめに 私は現在、個人的に 全文検索エンジン 学習をしています。 以前までは諸事情で Apache Solrをやっていたのですが、以下の理由からElasticsearchの学習に切り替えました。 シェアとそれに伴うドキュメントの充実 KibanaをはじめとしたElastic Stackの存在 クエリの書き方覚えたらいい感じにクエリ書けそう Apache Solr及びElasticsearchでは Apache Lucene いう OSS の 全文検索 ライブラリがコアになっております。 Lucene には Analyzer という機能があり、 全文検索エンジン において非常に重要な機能です。 今回は実際にElasticsearchでAnalyzerを設定しながら、Analyzerの仕組みを見ていきたいと思います。 検索エンジン の仕組み まずは簡単に 検索エンジン の仕組みを説明します。 検索エンジン ではあらかじめドキュメントのインデックスを作成しておき、そこへクエリが投げられるとそれにマッチするものがヒットするというのが基本になります。 Lucene では 転置インデックス という方式が採用されています。 転置インデックス は以下のような形で作成されます。 転置インデックス 何らかの方法でドキュメントのテキストを分割し、それに対応するドキュメントIDがリストになります クエリが投げられた際も同様、クエリのテキストを分割し、インデックスのキーにマッチした文章が返るという仕組みです。 Analyzerとは 先ほどは 検索エンジン の仕組みについて説明しました。 何らかの方法で分割する とありましたが、この部分がAnalyzerの仕事になります。 正確には、Analyzerは目的のインデックスを作成するために、テキストの分割や正規化などを行います。 Analyzerは以下の3つの機能で構成されています。 Char filter Tokenizer Token filter Analyzerの処理フローです。 Char filter → Tokenizer → Token filterの順に処理されます。 Tokenizerは必須・かつ一つ しか設定できません。 Analyzerの処理手順 前準備 今回はElasticsearchで動作確認を行います。 Analyzerがどのような動きをしているかどうかだけ知りたい方は飛ばしてください。 Java 8以上の環境が必須です。 Elasticsearchをインストール # brew brew install elasticsearch # yum yum install elasticsearch 日本語関連の機能と、テキストの正規化を強化する2つの プラグイン をインストールします analysis-kuromoj analysis- icu cd { ES_HOME } bin/elasticsearch-plugin install analysis-kuromoji bin/elasticsearch-plugin install analysis-icu Elasticsearchを起動して起動確認も行います # 起動 bin/elasticsearch # 起動確認 curl http://localhost:9200/ " name " : " 1GpZYN9 " , " cluster_name " : " elasticsearch " , " cluster_uuid " : " hoge " , " version " : { " number " : " 6.8.3 " , " build_flavor " : " oss " , " build_type " : " tar " , " build_hash " : " 0c48c0e " , " build_date " : " 2019-08-29T19:05:24.312154Z " , " build_snapshot " : false , " lucene_version " : " 7.7.0 " , " minimum_wire_compatibility_version " : " 5.6.0 " , " minimum_index_compatibility_version " : " 5.0.0 " } , " tagline " : " You Know, for Search " } これで準備完了です。これから実際にAnalyzerを作成しながら、Char filter, Tokenizer, Token filterについてそれぞれ解説します。 Char filter Char filterのポイントは以下の通りです。 テキストに対して 機械的 に前処理を行う 必須ではない いくつでも設定できる 機械的 な前処理というのは、例えば文字の全角↔半角処理だったり、 正規表現 による抽出などが挙げられます。 ここからいよいよAnalyzerの設定を行っていきます。 Elasticsearchでは様々な機能が REST API で操作できます。 今回はChar filterに以下を設定します。 icu _normalizer 記号・数字・ 特殊文字 などの正規化を行う kuromoji_iteration_mark 踊り字を正規化 踊り字とは々、ヽ、ゝのような前置の単語によって読み方が変化する単語のことです Analyzerを設定するにはインデックスを保管しておくスペースを作成しなければなりません。 今回はインデックス名を analyzer_handson として、Analyzerを設定していきます。 以下の json をmy_kuromoji_analyzer. json と保存し、POSTします。 { " settings ": { " analysis ": { " analyzer ": { " my_kuromoji_analyzer ": { " type ": " custom ", " char_filter " : [ " icu_normalizer ", " kuromoji_iteration_mark " ] , " tokenizer ": " keyword " } } } } } json を localhost :9200/analyzer_handson/ にPUTします。 curl -XPUT localhost:9200/analyzer_handson/ -H " Content-type: application/json " -d @my_kuromoji_analyzer.json これで my_kuromoji_analyzer というAnalyzerが設定されました。 早速テキストをアナライズしていきます。 ~/_analyze がエンドポイントになっており、こちらで特定のAnalyzerの挙動を確認することができます。 そこに以下の json をPOSTします。 { " analyzer ": " my_kuromoji_analyzer ", " text ": " コウテイペンギンは体格のいいものは１３０㌢あるという。僕は度々、コンピューターでそれを見て和んでいる " } curl -XPOST localhost:9200/analyzer_handson/_analyze -H " Content-Type: application/json " -d @query.json 以下のような結果が返ってきます。 { " tokens ": [ { " token ":" コウテイペンギンは体格のいいものは130センチあるという。僕は度度、コンピューターでそれを見て和んでいる ", " start_offset ": 0 , " end_offset ": 50 , " type ":" word ", " position ": 0 } ] } 無事正規化されています。 １３０は全角数字→半角数字 ㌢→センチ 度々→度度 に変換されています。 このような正規化の処理は 自然言語処理 の前処理として非常に重要です。 内部的には半角数字と全角数字などは違う文字として扱われるため、検索のノイズになることや、逆に欲しいドキュメントがヒットしないなどの問題が発生します。 踊り字などは主に古典などでノイズになることが多いです。 他にもChar filterはたくさんあるので、色々試していきたいところです。 Tokenizer Tokenizerはテキストを 分かち書き します。 分かち書き とは、特定の規則に乗っ取ってテキストを分割することです。 ではどのように 分かち書き するのかですが、日本語の場合は 形態素解析 もしくは N-gram を使用することが多いです。 形態素解析 や N-gram のTokenizerには以下のようなものがあります。 kuromoji_tokenizer 日本語用の 形態素解析 器であるKuromojiを使用して 形態素解析 を行う 辞書は2007年からメンテナンスされていないため、新語（芸能人の名前や流行語）などに弱い *1 N-gram Tokenizer 文字数で 機械的 に区切り、 分かち書き を行う 1-gramをuni-gram, 2-gramをbi-gram, 3-gramをtri-gramと呼ぶ 形態素解析 では、テキストを品詞単位で分解し、分割された単語のことを トーク ンと呼びます。 分解した トーク ンには品詞の情報はもちろん、活用形などの情報が付与されます。 Elasticsearchでは Kuromoji という日本語 形態素解析 器が用いられています。 もう一つの 分かち書き の手段の N-gram についてです。 例えばtri-graだとこのように分解されます N-gram 今回はtri-gramなのでテキストを3つに区切りながら一つずつ横にずらしていく感じです。 これら2つの手法はそれぞれ利点・欠点があります 形態素解析 辞書ベースで区切るため、辞書に載っている単語については比較的高い精度の検索結果を得やすい 逆に辞書に載っていない単語などは1文字区切りで 分かち書き されるため、未知の単語に弱い N-gram 機械的 に区切られるため、未知の単語などでもドキュメントをヒットさせることができる "京都で遊ぶ"のような単語で検索されたとき、上記の画像のように"東京都"を含むドキュメントがヒットする 検索ノイズが増えやすい どちらも一長一短なので、検索要件によって適切にTokenizerを設定する必要があります。 今回は 形態素解析 を用いて単語分割していきたいと思います。 Analyzerの設定を更新するために、まずは一旦インデックスをcloseします。 curl -XPOST localhost:9200/analyzer_handson/_close 次に、Char filterの時に使用したmy_kuromoji_analyzer. json のtokenizerを kuromoji_tokenizer に編集しPOSTします。 { " settings ": { " analysis ": { " analyzer ": { " my_kuromoji_analyzer ": { " type ": " custom ", " char_filter " : [ " icu_normalizer ", " kuromoji_iteration_mark " ] , " tokenizer ": " kuromoji_tokenizer " } } } } } # 更新する際は/_settingsにPOSTします curl -XPUT localhost:9200/analyzer_handson/_settings -H " Content-type: application/json " -d @my_kuromoji_analyzer.json 最後にopenして完成です curl -XPOST localhost:9200/analyzer_handson/_open 早速テキストを投げてみると以下のように 形態素解析 されていることがわかります。 { " tokens ": [ { " token ":" コウテイペンギン ", " start_offset ": 0 , " end_offset ": 8 , " type ":" word ", " position ": 0 } , { " token ":" は ", " start_offset ": 8 , " end_offset ": 9 , " type ":" word ", " position ": 1 } , { " token ":" 体格 ", " start_offset ": 9 , " end_offset ": 11 , " type ":" word ", " position ": 2 } , ... ~ ... { " token ":" 和ん ", " start_offset ": 45 , " end_offset ": 47 , " type ":" word ", " position ": 21 } , { " token ":" で ", " start_offset ": 47 , " end_offset ": 48 , " type ":" word ", " position ": 22 } , { " token ":" いる ", " start_offset ": 48 , " end_offset ": 50 , " type ":" word ", " position ": 23 } ] } 無事Kuromojiを使用して 分かち書き をすることができました。 最後はToken filterです。 Token filter Token filterではTokenizerで 分かち書き された トーク ンに対して様々な変換処理を行います。 以下はToken filterの一例です。 Lower case Token filter トーク ンを全て小文字に変換する Stop Token filter ストップワード の除去を行う ストップワード とは、 自然言語処理 において、一般的であるなどの不要な単語のこと Stemer Token filter 語幹ごとに定義されたステミング処理を行う ステミングとは語形の変化をなくし、表現を統一すること Synonym Token filter 類義語の展開を行う 表記揺れ（引越し、引っ越し、引越）や類義語（パソコン、PC、コンピュータ）など Kuromoji-Analysisに付属しているToken FIlter kuromoji_baseform 動詞・形容詞を原型に戻します。活用形は表記揺れの原因になります。 kuromoji_part_of_speech 特定の品詞を削除します。検索において、助詞や助動詞などは必要でないケースがあります。 デフォルトでは {助詞-格助詞-一般, 助詞-終助詞}を削除します。 形態素解析 を行うことによって、単語に品詞情報が付与されます kuromoji_stemmer 日本語に特化したステミング処理用のToken filter。カタカナの伸ばし棒を削除します。 今回は上記の KuromojiのToken filter 3種と、 Synonym Token filter , Stop Token filter を使用していきます " コウテイペンギン "で一単語であり、"ペンギン"で検索した時にヒットしない 二つの単語を一つのシノニムグループ *2 として扱うmy_synonym_penguin_filterを新しく作成し、filterに追加 動詞や形容詞であるが、いい、もの、ある、いるなど様々な文章で頻出しそう。文章の特徴を表さないのでなくても構わなそうな単語がある *3 頻出しそうな単語をstopwordsに追加 { " settings ": { " analysis ": { " analyzer ": { " my_kuromoji_analyzer ": { " type ": " custom ", " char_filter " : [ " icu_normalizer ", " kuromoji_iteration_mark " ] , " tokenizer ": " kuromoji_tokenizer ", " filter ": [ " kuromoji_baseform ", " kuromoji_part_of_speech ", " kuromoji_stemmer ", " my_synonym_penguin_filter ", " my_stop_filter " ] } } , " filter ": { " my_synonym_penguin_filter ": { " type ": " synonym ", " synonyms ": [ " コウテイペンギン,ペンギン " ] } , " my_stop_filter ": { " type ": " stop ", " stopwords ": [ " いい ", " もの ", " ある ", " いう ", " それ ", " いる " ] } } } } } 設定を適用したら同じクエリを投げていきます。 すると以下のような結果になりました。 { " tokens ": [ { " token ":" コウテイペンギン ", " start_offset ": 0 , " end_offset ": 8 , " type ":" word ", " position ": 0 } , { " token ":" ペンギン ", " start_offset ": 0 , " end_offset ": 8 , " type ":" SYNONYM ", " position ": 0 } , { " token ":" 体格 ", " start_offset ": 9 , " end_offset ": 11 , " type ":" word ", " position ": 2 } , { " token ":" 130 ", " start_offset ": 17 , " end_offset ": 20 , " type ":" word ", " position ": 7 } , { " token ":" センチ ", " start_offset ": 20 , " end_offset ": 21 , " type ":" word ", " position ": 8 } , { " token ":" 僕 ", " start_offset ": 27 , " end_offset ": 28 , " type ":" word ", " position ": 12 } , { " token ":" 度度 ", " start_offset ": 29 , " end_offset ": 31 , " type ":" word ", " position ": 14 } , { " token ":" コンピュータ ", " start_offset ": 32 , " end_offset ": 39 , " type ":" word ", " position ": 15 } , { " token ":" 見る ", " start_offset ": 43 , " end_offset ": 44 , " type ":" word ", " position ": 19 } , { " token ":" 和む ", " start_offset ": 45 , " end_offset ": 47 , " type ":" word ", " position ": 21 } ] } しっかり設定したToken filterの効果が表れています kuromoji_baseform（原型へ変換） 見て→見る 和ん→和む kuromoji_part_of_speech(助詞-格助詞-一般, 助詞-終助詞の削除) コウテイペンギン "は" 、コンピューター"で"などが削除されています kuromoji_stemmer（語幹の統一） コンピューター→コンピュータのように伸ばし棒が除去されています Synonym Token filter コウテイペンギン が コウテイペンギン とペンギンの二語に展開されています Stop Token filter 設定した"いい", "もの", "ある", "いう", "それ", "いる"がそれぞれ除去されています。 おわりに 実際にAnalyzerを設定してみました。 Analyzerだけではなく、他にも様々な機能がElasticsearchにはあります。 次は検索ネタを話せたらと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : MeCab 用の新語対応辞書 mecab -ipadic-neologdを適用した、Kuromojiの プラグイン があります *2 : 双方向展開 *3 : 実際に使用する際は公開されている ストップワード リストをメンテナンスするのが良い