あざらし備忘録。

音ゲー好きなウェッブエンジニアがいろいろ思った事やった事を書いていくブログです

HHKBをMac上に載せて快適に使うたった一つの簡単な方法[ネタ]

MacHHKBを乗っけて開発したいですよね。

えっしたくない?アーアーキコエナーイ

ただ普通に乗っけちゃうとMac側のキーボードが反応して大量の謎の文字が打たれてしまったり、運が悪いと電源ボタンを押されて強制終了とかされたり。つらい。

どうにか上手く快適に出来ないかなーと思ってググッてはみました。

jigsaw.hatenablog.jp

あーわかるわかる。良さそう。でもアクリルなんてないし注文するの面倒くさいな...

detail.chiebukuro.yahoo.co.jp

あーわかるわかる。良さそう。でも質問者と同じ感じで無効にするのはな〜って感じなんだよね...

そこで思いついてしまったのがこちら!!!!最高!!!

いやー本当いろはす最高ですよ。もう手放せません。(別にキャップはなんでも良い)

いろはすはいいぞ。

AmazonWebServices実践入門を読み進めている[AWS][GitBook]

発売当初買って、しばらく家に鎮座していた AmazonWebServices実践入門 を最近読みはじめた。

www.amazon.co.jp

業務であまりAWSを一からガッツリ触れておらず、このままだとAWSを微妙に使えるけどよくわかってない、みたいなよろしくない状態になってしまうなぁと危機感を覚えていて、良い機会なので読みながら実際に色々試してみている。

今後はHerokuで動いているサービスをAWSに載せ替える、とかやって遊びたいなぁなどと。

AmazonWebServices実践入門は、実際にマネジメントコンソールから色々と試しつつ、適宜解説を入れてくれる感じでなかなか読んでいて楽しい構成になっているのでオススメかもしれない :)

また、少し前に書いたエントリーでGitBookを使えるようになったので、今回の本を読んで得た知識はGitBookを通じてアウトプットするようにしてみた。

gomachan46.gitbooks.io

(以前書いたエントリーはこちら)

shiro-goma.hatenablog.com

やっぱりすごく書き味が良いのですぐ良い感じにHTML化できるしそのまま公開もできるので楽ちんで素晴らしいです。

今後主にはちょっとまとまったアウトプットはGitBookで書いて、それの告知みたいな形でブログを書く、みたいなスタンスになりそう。

まだEC2周りまでしか読めてないので、引き続き試しつつ一通り使えるようになりたいな〜

markdown文書をhtmlなどに変換して公開・共有できるGitBookを試してみた[Git][Markdown][GitBook]

f:id:shiro_goma:20160314033908p:plain

感想。めっちゃよかった。

実際に一通り使ってみた情報をまとめてGitBookで公開までしてみたので、詳細は以下のURLからどうぞ。

gomachan46.gitbooks.io

概要についてはgitbook.com側のページからでも見れて、htmlの他pdfでのDLとかも出来て便利!

www.gitbook.com

今回の情報をまとめたリポジトリは以下。

github.com

所感

ちょっとGitBookの良さを活かして階層化とか無駄にして書いたので内容の割に長文化しましたが、とても簡単に、そして良い感じに文書の公開までを行うことが出来ました:)

使い方もはじめに要点だけ抑えてしまえばほぼ難しいことはないので、学習コストもほとんどかからない良いツールだと思います。

gitbook.comGitBookコマンドが良い感じに分離されているのも素敵ですね。

これから文書をちょっとまとめて書きたい時とかは使っていこうと思います!

React+Reduxでreact-dropzoneを用いてファイルアップロードを行うサンプルを作ってみた[JavaScript][ES6]

今回はフロント側だけでファイルアップロードのサンプルを作ってみた。

あとはサーバーにファイルの情報を送れば良いだけなのでいつも通りな方向に持っていけそう。

遊んでみたリポジトリはこちら。

github.com

ファイルアップロード用のライブラリとしてはreact-dropzoneを使ってみた。

github.com

パッと検索した限りだとこのライブラリと、あともう一つ名前のよく似たreact-dropzone-componentが目についたけど、今回はreact-dropzoneの方を選択。

github.com

理由はシンプルそうだったから。

後者の方はリッチな感じに仕上がっていたけどその分外部ライブラリに依存していたり、導入がちょっと面倒そう&メンテとか考えた時にうーんという感じになったので見送り。

実際今回使った方は1ファイルでできてる程度にはシンプルだったので中身はだいぶ見やすかった。

まぁまぁスムーズに行けそうな感じがつかめたので、趣味プロダクトにちょっと突っ込んでみて見ようかなーと思う。

以下、READMEの転載。

react-redux-file-upload-example

React+Redux環境に react-dropzone を入れてみてフロント側のファイルアップロードをして遊んでみるテスト

react-dropzone

https://github.com/okonet/react-dropzone

install

npm install --save react-dropzone

usage

import Dropzone from 'react-dropzone'

// ...

<Dropzone
  onDrop={func}
  onDropAccepted={func}
  onDropRejected={func}
  accept="image/gif,image/jpeg,image/png,image/jpg" >
    <div>
      ファイルを指定またはドラッグ&ドロップ
      <p>形式: gif/png/jpeg/jpg</p>
    </div>
</Dropzone>

ファイル選択後に実行するコールバックに関してはonDropプロパティで指定できる。

ファイル形式の制限もacceptプロパティを使ってカンマ区切りで行える。

ファイル形式の制限に選択したファイルが全て則っていた場合はonDropAcceptedプロパティにて指定されたコールバックを実行し、則っていないファイルが一つでもあった場合にはonDropRejectedプロパティにて指定されたコールバックが実行される。

今回は指定してないが以下のような設定も可能

  • 複数ファイルの選択を許可するか(multiple: デフォルトtrue)
  • ウィンドウをクリックした時にアップロードファイルを選択する画面を表示するかどうか(disableClick: デフォルトfalse)
  • プレビューを表示するかどうか(disablePreview: デフォルトfalse)

デザインに関しても外から好きに渡せるので、カスタマイズしてあげれば良さそう

  • style 基本のstyle
  • activeStyle acceptedな時のstyle
  • rejectStyle rejectedな時のstyle

の三種類のstyleを渡せるようになっている。

styleを基本として、accepted/rejectedなstyleがマージされて適用されるイメージ。

本体のソースもとても小さいものなので一通り見ると良さそう

https://github.com/okonet/react-dropzone/blob/master/src/index.js

所感

一通りいじってみたけど特段苦労はしなかった感じ。

あとは今回はサーバーと繋いで実際にファイルのやり取りを行うところまでいけてないのでそのあたりで躓かなければスムーズっぽい。

サーバーとのやり取りのところも公式のREADMEにSuperAgentを用いたサンプルが出ているので割と楽には出来そうな感じはある。

React+Redux+ES6で動くSPAをMocha+power-assert+Karmaで小さな構成でテストできるようにしてみた[JavaScript][テスト][入門]

練習として作ってみた。

github.com

f:id:shiro_goma:20160214164617p:plain

redux-test-exampleとか言ってるけどもろReactも込み想定でのexampleです。

今までJS周りのテストはまともに触ったことがなくて、かつ周辺ツールも触ったことがなかったのでその辺りも軽く触れてみてまとめてみた。

小さく始めた感じがあるのでもっと良いツールが〜、とかはありそうだけど今回は一旦見ずに「とりあえずReact+Redux+ES6で動くSPAをテストできるようにするぞ!その他も学べたらいいな!」くらいの温度感でさらっとやってみました。

以下GitHubのREADME転載。

使ったもの

  • React
  • Redux
  • ES6
  • Mocha
  • power-assert
  • Karma

ついでに使ったもの

  • browserify
  • babelify
  • babel-preset-es2015
  • babel-preset-react
  • browser-sync
  • watchify

requirements

npmが使える環境

install

make install

これでとりあえず環境は揃うはず

build

make build

React+ES6なやーつをbrowserifyとbabelifyを用いてビルドする。

設定値として.babelrcに記述されている内容が用いられる

public/bundle.jsにビルドされた内容が書き込まれる

tests

今回は勉強用にMocha単体で動かすテストとKarma経由で動かすテストを用意してみた。

まぁでもReactだのReduxだのをテストしていくんだったらKarma経由になるのかな?

Mocha Test

make tests

compilerとしてpower-assert化+ES5化+React化するような設定をはさみつつMochaでテスト実行する。

--watchオプションを入れているのでファイルの変更を検知して勝手にテストが回ってくれる。

Karma Test

make browser-tests

Karma経由でテストが実行される。

karma.conf.jsが設定値として読み込まれる。

この中で * テスト対象のファイルの設定 * Mochaで動かすようにする設定 * Browserifyを噛ませてビルドする設定 * ビルド時にBabelifyを使うようにする設定 * プラグインとしてpower-assert化+ES5化+React化する設定 * ...etc

などなどをよしなにしている。

変更検知の設定も入れているのでこちらもmake tests同様ファイルの変更を検知して勝手にテストが回ってくれる。

ブラウザの指定としてChrome決め打ちで今回は雑に設定したので、Chromeが使える環境じゃないと動かない。

ちゃんとするならデフォルトは指定せずにコマンド実行時にオプションで渡すのかな?

動作サーバー構築

make server PORT=xxxx (default: 3000)

watchifyを使ってファイルの変更を検知してよしなに自動ビルドしつつ、browser-syncを使ってpublicディレクトリ下にサーバーを立てている。

PORTのデフォルトは3000番のようだけど変えたい場合もあったので--portオプションを通すようにした。

雑に&つなぎで実行してるけどもう少し上手くやれるかな。Foremanでもこしらえればよいかな?

メモ

今回ので学んだなんとなくの所感。

Mocha

JavaScriptのテスティングフレームワーク

power-assert

assertにすべての情熱を注いでassertが落ちたときにわかりやすい情報を表示してくれるテストツール

「とりあえずassertだけ使えばOK」っていうスタンスにもってけて学習コストも少なくなって素晴らしい!

Karma

複数の実際のブラウザでテストが行えるテストランナーツール

「実際のブラウザだと正しく動きませんでしたー!ババーン!」みたいな自体になりにくくなる

KarmaでMochaなど諸々を包んでよしなに状態で実際のブラウザでのテストを走らせられるようにできる。

Browserify

モジュール感の依存解決やファイルの結合を行うためのビルドツール

Nods.jsのモジュールをブラウザでも、といったことがもともとの内容だったけど最近は専らビルドツール側としてメリットからの登用が多い様子。(始めたばかりなので歴史はあまりわかっていない)

「いっぱいjsのファイルがあるけども、とりあえずバンっとビルドして一纏めにしてあげるよ!あとは出来上がった1ファイルをhtmlで読み込んであげるだけだよ!楽ちんでしょ!」みたいなノリの需要と思っているw

Babelify

Browserifyするときによしなにバベって上げる君。

※ バベる・・・「ES6で書かれていたりReactで書かれていたりするのをよしなに普通の環境で動くようにしてあげる」的な意味と思っている

babel-preset-es2015

「ES6で書かれているのをよしなに普通の環境で動くようにしてあげる」君

babel-preset-react

「Reactで書かれているのをよしなに普通の環境で動くようにしてあげる」君

browser-sync

「変更を検知してブラウザ更新もよしなにしてくれる」君

指定したポートにローカルサーバーと立ててくれて、そこで動作確認をできる

ファイルを更新してブラウザを見たらもう反映されてる!みたいな感じ

また、いろいろなタブだったりブラウザだったりを起動して立てたサーバーにアクセスしてても全てよしなにブラウザ更新をかけてくれる

おまけにbrowser-sync用の管理画面も立ててくれていて、そこで現在の接続数だったり、通信速度の制限をかけてどうなるかを見たり、といったことができる。

localhost:3000 にて画面が表示されるので動作を確認して、localhost:3001で管理画面を表示していろいろいじってみたり、といった使い方ができる。

ただ、今回触った感じだとパット見「変更を検知した時にビルドをしてブラウザ更新までよしなにしてくれる」みたいなとこまではできなさそうだったので、次にメモするWatchifyの方向からサポートした。

Watchify

「変更を検知した時にビルドをしてくれる」君

変更を検知してBrowserifyを走らせられる感じ。

これがあればまぁ開発時は手動ビルドすることはないんじゃないかなと思った。

デプロイの時とかは明示的にBrowserifyでビルドしてぽん起きデプロイとかになるのかな?

browser-syncの時に書いたように今回はWatchify+browser-syncで「変更を検知した時にビルドをしてブラウザ更新までよしなにしてくれる」機構を作った。

けどこれbrowser-syncの方でよしなにできそうだな〜できないのかな〜なんて思いつつw

所感

とりあえず今まで全然わかってなかったライブラリ周りに触れて実際に動かせてなんとなくはわかったので良かった!

Herokuで超絶簡単に15秒で管理画面を作る[Heroku][Adminium]

明けましておめでとうございます(遅い)

一発目なので軽めのTipsから。

年末から完全趣味のサービスを動かしてます。

my-chunithm.net

「Herokuで動かしている趣味サービスの管理画面欲しいけど面倒だな〜どうしようかな〜」とか思って色々探していたらすごい楽ちんに適当な管理画面が出来たのでメモとして。

全然他の記事等が見つからなかったので(特に日本語は皆無)w

elements.heroku.com

https://s3.amazonaws.com/assets.heroku.com/addons.heroku.com/screenshots/57/medium.png?1448987936

手順なんてほとんどなく、普通に先ほどのURLをクリックして、HerokuのAdd-onとして登録したらもう普通に使えちゃいます。

「管理画面をアプリケーション側で用意するのもなぁ〜」みたいに思った方には是非おすすめです。

基本はHerokuらしく無料で使えます。

  • 基本的なCRUD機能
  • 関連テーブルの任意のカラム表示
  • データインポート機能
  • データエクスポート機能
  • 各種ソート・絞込
  • データのグラフ描画
    • Time Chart
    • Pie Chart
  • データの統計情報表示
  • 各種検索機能
  • etc...

などなど、基本的な機能はぱぱっと揃ってとてもいい感じです。

アプリに全く手を入れずに瞬時に管理画面が手に入るのはとても良いですね。

趣味アプリだと特にこれくらいの簡単な管理画面でも事足りるので、大満足です!

ただし料金設定は結構強めで、無料だと Admin Userは一人のみ、管理画面対象にするテーブルは5テーブルまで という感じになってます。5テーブル...ウッ...

今回の僕の用途だと5テーブル内に収まっているので良いのですが結構引っかかるパターンも出てきそうですね。

次のプランの$10/monthだとテーブル数が無制限になるのでだいぶ良くなりそうです。

まずはお試しで触って見る分には申し分ないAdd-onだと感じたので是非遊んでみてください!

新卒1~2年目として過ごした2015年エンジニア業を振り返るぞい[振り返り][お疲れ様でした]

早いもので2015年も終わってしまう...w

今年は(今年も?)結構色々あったかなと思うので、忘れないようにざっと振り返ってみる。

つらつらと書いただけなのでまとまりとか学びとかないけどまぁブログだし良いよね!w

みだし

新年早々突然任されたリーダー業

新年明けましておめでとう空気もまだ残っていた1月始め、突然とあるプロジェクトのリードエンジニアを任されるなどしたw

なかなか激動のスタートだった気がするw

正直全くそういったたぐいの動きを今までの人生でしたことはなかったので、不安や戸惑いでいっぱいだったけど、「まぁ自分なりに頭を使って動いていい感じに着地できるように頑張ってみます。都度色々相談とか質問とかさせてくださいw」と先輩に伝えた記憶がある。

この経験はやっぱりめちゃくちゃためになって、主に全体を見る力、また全体を繋ぎ合わせるために動く力がパワーアップした気がする。

営業サイドの人だったり、パートナー企業の人だったり、あとは社内の他部署の人とのやりとりだったり、プロジェクトを進めていくうえで必要になってくる開発以外のタスクも色々触れる事が出来て、あんまり馴染みがなかったけど今ではその辺りも足の運びがだいぶ軽くなった気がする。

(プロジェクトにアサインされていたエンジニアは僕含めで2人だったのでもちろん開発力もグッともう一歩伸びたと思うw)

この時使っていたのは言語はPHPフレームワークはSymfony2。新卒で入社して7月頃からSymfony2を使い始めていたので、1年半程大変にお世話になりました。

Symfony2、本当いいフレームワークだと思いますw

1月から諸々見積もりだったり準備段階を始めて、本格的に開発を始めたのが2月頃から。そして7月にリリース完了して、今のところ特段大きな事故もなくあまり世話のかからないシステムとして動いてくれている。

とりあえずはプロジェクトは成功、ということですごくホッともしたし、自信もちょっと着いたと思う:)

とはいえでファーストリリースめがけてある程度は取捨選択を行ってきたので、その「捨てた」部分の継続的な回収をしていきたいところ。

新卒氏の配属

4月になって、上で書いたプロジェクトを進めている中、新卒氏が僕のいる部署にも入ってきた。エンジニアは一人。

そしてその新卒氏は僕のプロジェクトへ配属&僕が指導係(?)となった。

わかってはいたけれど、やはり実際に配属されてくると「あー2年目だなぁw」という実感も湧いてきたw

そんな新卒氏、僕は大卒、彼は院卒で、年齢的には1個下になるので若干変な感覚はあったけれど、まぁなるべくそこは気にしないようにw

新卒氏とのコミュニケーションで気をつけていたこと

とにかく質問・相談しやすい環境を作ること、話す垣根をなるべく低くすることを意識してみた。

聞いてくれたら腹落ちするまで付き合う。「今忙しいから後で」みたいなコミュニケーションは取らない。

夕会など軽いコミュニケーションの場を設けてそこでヒアリングしてみたり。

やっぱり教える側から一方的にぶつけても響かないし、身につかないと思うので、一度自分事として考えてみて、興味を持った上で話し合いに進むのが効率よい吸収の仕方かなぁと思うので、その「自分事として考えたけどなるほどわからん」となってからの初動を早くしてあげたいという意図で、「とにかく質問・相談しやすい環境を作ること」は大事にしてたし、今もしている。

(僕自身、あんまりおしゃべりなタイプの人間ではないのでそういう関係値を作れているか若干不安だけど!w少なくとも話しづらい雰囲気をまとった先輩にみられてはいないんじゃないかな!w)

また、意思を伝えてもらうことも大事だと考えているので、「どうだと思う?」のような自分で考えてもらうようなことも意識的にやっていたと思う。

例えば設計だったり実装だったりの相談をする時、「自分でメリット・デメリットを考えた結果、こうしたら良いんじゃないか、と思って選択しました」みたいなのをちゃんと伝えてくれて、それが他者の目から見ても良さそうに見えるならそれは正解だと思うので、そういったコミュニケーションが取れるようになってほしいな、と思って。

正直新卒氏は、こういった「自分から質問する」だったり「自分で考えて選択して実行する」みたいな「自分駆動」の動きが苦手な所があるように感じました。

だけど、こういったコミュニケーションを取っていったことで段々と「自分で考えてる」感じが見て取れるようになってきて、発言に説得力が出てきました最近。良かった良かった。

「こういうケースは大丈夫?」みたいな投げかけをちょっと他の人にされると意思がぐらついて行動がちぐはぐになるケースが結構見られたのだけど、最近は「あーそれも考えたんですけど〇〇だなぁと思って」みたいな返しも増えてきて、頼もしくなってきました。引き続き期待してます!!1

エンジニアインターンシップへサポーターとして参加

弊社、毎年8月あたりに3週間程の割と長い開発インターンシップがあるのですが、それのサポーターをさせてもらってました。

このインターンシップは僕も学生の時に参加させてもらっていて、かなり人生を変えてくれたインターンです。

大学3年までほぼプログラミングをまともにやってこなかった勢の僕が、運良く参加させてもらえて、開発の楽しさを身を持って味あわせてくれて、本当になんとなく「SIerかな〜」なんて仕事を考えていたのをゴリゴリ開発する方に完全シフトさせてくれた、本当に思い出深いインターンですw

今回サポーターとして学生さんたちのパワーあふれる姿を見て、すごく懐かしくなったし、「ものづくり」の楽しさを再認識させて貰えました。ありがとう!

ギョームのプログラミングももちろん楽しい。けどこういった純粋なものづくりって最近あんまり出来ていないなーと考えさせられ。

あの時からきっかけにちょっとずつ趣味プログラミングの時間を増やすようにしました。

毎日コミット活動

インターンで再認識したものづくりの楽しさから、趣味プログラミングの時間を増やしていこうと思っていた僕に拍車をかけたのが以前ブログも書いたコレでした。

shiro-goma.hatenablog.com

毎日本当にちょっとでも良いからプログラミングする習慣をつける。そんな活動を始めました。

これを始められて、かつ継続できているのは本当に新卒氏のおかげ!ありがとう!!

f:id:shiro_goma:20151231012028p:plain

現在継続85日。頑張るぞい

毎日コミット活動で出来たこと

振り返りの一つとして。

自分のスタイル的なところの変化で言うと、

  • プログラミングの習慣
  • 基本的にpublicにして公開するクセ

この辺りが板についてきました。

新しく学べたことでいうと、この9-12月は全くわからなかったjs界隈に主に触れ始められました。

振り返ると片手間ながらそこそこ実りがあって良かった!という気持ち。

まだjs界隈のテスト書けてなくて糞なので、そのあたりも今後この活動を通じて吸収していきたい気持ち。

是非続けてやっていきたい:)

PHPカンファレンス2015登壇

とてもとても思い出深く残った体験。本当にありがとうございました!

以前ブログにも書きました。

shiro-goma.hatenablog.com

上記記事にもある通り、PHPカンファレンスは「大学3年の時に初めて行ったカンファレンス」だったんですよね。

インターンしかり、カンファレンス登壇しかり、2015年は大学3年の時の思い出深いイベントの再出現、みたいなところがあって、その頃よりちょっとステップアップした自分を実感することもできて、なんだか不思議な気持ちですw

Railsプロダクトへのアサイン

先に書いたリーダー業が一段落した後、僕のいる部署で開発が行われているプロダクトが若干進捗がよろしくないということで、部署内異動ががが。

そのプロダクトがRailsプロダクトで、この3ヶ月ほどはRailsも書いてた人生だった。

今までRubyは割と好みで使っていましたが、Railsは初めてだったので新鮮でした。

RailsとSymfony2と、割と対極的な2大フレームワークを触ることが出来て、両者のメリットデメリットを噛み締めながら開発出来たのはすごく良い経験w

本当に良さのポイントが各々違って面白いw

年明け3月くらいまではRailsを書くかなと思うけど、だいぶ業務ドメインしかりRailsしかりわかっては来て、スピードが乗ってきた感じもあるので年明け後も引き続き頑張って行きたい所存。

おわり

良い一年でした!!

良いお年を :)