homebrew cask で cocoscreatorv2.0.5 をインストールできるようにPRを出した

概要

homebrew caskでcocoscreatorというappを入れたかったのですが、versionが古いものしか登録されてませんでした。
そこでhomebrewについて調べてみたところ、GitHub上でOSSとして運用されていました。
僕個人からpull request(以下PR)を投げることができたので、投げてみました。
(人生初OSSヘのcommitです)

PRを作る上で何かと手間取ったので備忘録的に書き残します。

1. homebrew caskのrepositoryをfork - cloneする

github.com

homebrewのGitHubページに移動してforkします。
forkしたのち手元にforkしたrepositoryをcloneして手元で編集できる状態にします。

$ git clone git@github.com:[各自のユーザー名]/homebrew-cask.git homebrew-cask

2. cocoscreatorの最新パッケージを用意する

2-1. version情報をメモする

homebrewにversionを記載する箇所があるため、version情報を手元にメモしておきます。
大体appのパッケージ(.exeや.dmg)にversion情報が載っているので、それを参照します。
今回利用したcocoscreatorは以下のような形式になっていたので、v2.0.5_2018110602 を書き留めておきます。

CocosCreator_v2.0.5_2018110602_mac.dmg

2-2. sha256のhashを作る

homebrewでは、改ざんなどを行ったパッケージが登録されていないか、不正防止用にパッケージごとhashが登録されています。
sha256のhashを作るためには以下のコマンドを利用します。

$ shasum -a 256 [パッケージ名]

このコマンドにて生成されるhashを書き留めます。

2-3. パッケージのdownloadに利用されるURLをメモする

パッケージの配布にCDNを利用していることがよくあるため、CDNで実際に利用されるURLを突き止める必要があります。
今回はMacで .dmg 形式のファイルをダウンロードしていたので、ファイルの詳細情報を見て実際のdownload URLを突き止めることができました。

3. homebrew caskの編集をしてcommitする

cloneしてきたrepositoryの Casks/ 以下に、パッケージごとにrubyで実行内容が書かれています。
今回はcocoscreatorのcaskを編集したいので、 ./Casks/cocoscreator.rb を開きます。

大体どのcaskも下記のような内容になってます。

cask 'example' do
  version ''
  sha256 ''

  url ''
  name ''
  homepage ''

  app ''
end

項目	内容
version	バージョン情報/番号
sha256	sha256のhashが記載されている。不正改ざん防止に利用される。
url	パッケージのダウンロードに利用するURL
name	アプリケーションの名称
homepage	アプリケーションのホームページ。今回だったらcocoscreatorだから、 http://www.cocos2d-x.org/creator といった感じ。
app	.appファイルの名称

今回はversion upのために編集をするだけなので、

• version
• sha256
• url

と3種類の編集をすればお終いです。

PRを出す

homebrew caskではPRを出す際に、PRのコメントとしてテンプレートが準備されているため、テンプレートに沿って確認を行いcheckboxにcheckを入れるだけでOKです。
具体的には以下の4つ。

After making all changes to the cask:

• brew cask audit --download {{cask_file}} is error-free.
  このコマンドを実行してエラーが出ないかどうか。
• brew cask style --fix {{cask_file}} reports no offenses.
  このコマンドを実行してstyle checkが通るかどうか。
• The commit message includes the cask’s name and version.
  コミットメッセージにcaskの名前とバージョンが記載されているかどうか。
• The submission is for a stable version or documented exception.
  安定板、もしくは文書化されているような例外のものかどうか。

まとめ

まだPRはmergeされていませんが、人生初のOSS貢献(?)としてPRを出してみました。
gitのお作法さえわかっていれば意外とPR出すのは大変じゃありませんし、OSSのコードも読んでみてなんとなく理解できました。
(あまりruby経験ないのですが、過去のcommitから雰囲気で察しました)
自分の中でOSSへの参加ハードルがぐっと下がった感触を得ています。

実際に出したPRはこちら。
Testは通ってるの確認できたので、mergeされたら嬉しいなと。

github.com

追記(2018/11/18 19:00くらい)

無事mergeされてました！
人生初のOSS貢献達成です。

macでcocos2dxの開発環境セットアップをする

概要

転職先でcocos2dxを利用しているので、勉強としてcocos2dxで簡単なゲームを作ってみることにしました。
環境構築周りは大体忘れて悲しい思いをするのでメモとして残しておきます。

cocos2dxのセットアップをするにあたって、android-sdk/ndkやjavaなどいろいろと入れる必要があったので、全てhomebrewで入れてみました。

cocos2dxのダウンロード

www.cocos2d-x.org

こちらからダウンロードします。
zipが手に入るので、展開してmacの /Applications フォルダに置きます。

javaのセットアップ

既にjavaが入ってたので、この機会に古いjavaを削除してhomebrew経由で入れてみました。
削除方法についてはこちらのリンクを参照。

macOSで古いJDKをアンインストール - Qiita

削除できたことが確認できたらhomebrew経由でinstallします。

brew cask install java

これだけでinstall終わります！homebrew便利！

android-sdk/ndkのセットアップ

brew cask install android-sdk
brew cask install android-ndk

apache antのセットアップ

brew install ant

cocos2dxのセットアップ

cocos2dxに必要なライブラリもろもろが揃ったので、cocos2dxそのもののsetupをします。
cocos2dxを置いたディレクトリに移って、

$ ./setup.py

Setting up cocos2d-x...
->Check environment variable COCOS_CONSOLE_ROOT
  ->Search for environment variable COCOS_CONSOLE_ROOT...
    ->COCOS_CONSOLE_ROOT is found : /Applications/cocos2d-x-3.17/tools/cocos2d-console/bin

->Check environment variable COCOS_X_ROOT
  ->Search for environment variable COCOS_X_ROOT...
    ->COCOS_X_ROOT is found : /Applications

->Check environment variable COCOS_TEMPLATES_ROOT
  ->Search for environment variable COCOS_TEMPLATES_ROOT...
    ->COCOS_TEMPLATES_ROOT is found : /Applications/cocos2d-x-3.17/templates

->Configuration for Android platform only, you can also skip and manually edit "/Users/jalemy/.bash_profile"

->Check environment variable NDK_ROOT
  ->Search for environment variable NDK_ROOT...
    ->NDK_ROOT not found

  ->Search for command ndk-build in system...
    ->Path /usr/local/Caskroom/android-ndk/18 was found

    ->Error: "/usr/local/Caskroom/android-ndk/18" is not a valid path of NDK_ROOT. Ignoring it.
->Check environment variable ANDROID_SDK_ROOT
  ->Search for environment variable ANDROID_SDK_ROOT...
    ->ANDROID_SDK_ROOT not found

  ->Search for command android in system...
    ->Path /usr/local/Caskroom/android-sdk/4333796 was found

  -> Add ANDROID_SDK_ROOT environment variable...
    ->Added ANDROID_SDK_ROOT=/usr/local/Caskroom/android-sdk/4333796

->Check environment variable ANT_ROOT
  ->Search for environment variable ANT_ROOT...
    ->ANT_ROOT not found

  ->Search for command ant in system...
    ->Path /usr/local/Cellar/ant/1.10.5/bin was found

  -> Add ANT_ROOT environment variable...
    ->Added ANT_ROOT=/usr/local/Cellar/ant/1.10.5/bin


A backup file "/Users/jalemy/.bash_profile.backup1" is created for "/Users/jalemy/.bash_profile".

Please execute command: "source /Users/jalemy/.bash_profile" to make added system variables take effect

setup.pyを実行すると上記の通りandroid sdkやndk、antのpathが聞かれます。
今回のようにhomebrew経由で入れた時は特に困らないはず……
setup.py により .bash_profile が更新されるので、 .bash_profile の内容を軽く確認して、言われるがままに

source ~/.bash_profile

を実行します。 これによって .bash_profile の再読み込みが行われます。

cocosコマンドが通ることを確認

terminal上で

cocos

とコマンドを入力します。 無事に環境設定ができて入ればcocosのコマンド一覧が出力されます。

まとめ

homebrew経由でjava/android-sdk/android-ndk/apache antを入れてcocos2dxのセットアップをしました。

とりあえずcocos2dxのデモアプリとか動かしつつ、軽くテスト用のプロジェクトを作って、何か遊べるゲーム作ろうかなと。

.jarファイルをdecompileして中身を見る

概要

業務中に hoge.jar という形でパッケージ化されたコードの中身が見たくてどうしようもない状況に陥ったのでやりました。
既に初期の開発メンバーがいなくてライブラリを把握してる人がいないとか、聞ける人がいないとか……
ポジティブに考えるならば、デバッグのためとか勉強目的として利用すると良いかもしれません。

jarファイルを解凍する

terminalにて unzip hoge.jar と打てばjarファイルの解凍が出来ます。
出力結果はこんな感じに

$ unzip hoge.jar
Archive: hoge.jar
inflating: META-INF/MANIFEST.MF
inflating: fuga.class
inflating: piyo.class
inflating: poyo.class
inflating: hage.class
...

classファイルをdecompileする

カレントディレクトリ直下にjarファイルを解凍した結果得られたclassファイルの大群がいます。
そのclassファイルをdecompileします。

decompileに使うコマンドはこちら

javap

参考
javap

javapコマンドは、1つ以上のクラス・ファイルを逆アセンブルします。出力は指定するオプションにより異なります。オプションを使用しない場合、javapコマンドは、そのパッケージ、渡されたクラスのprotectedおよびpublicのフィールドとメソッドを出力します。javapコマンドは、その出力をstdoutに表示します。

javap hoge.class

といった感じでclassファイルへのpathを渡せば標準出力でdecompile後のコードが出てきます。

複数の.classファイルを一括でdecompileする

今回は拡張子が .class になっているものだけ対象としたいので、 find コマンドを利用して一括でdecompileします。

find [ディレクトリ名] -name "*.class"

上記のコマンドで拡張子が .class になっているものが一覧で取れます。
この結果を javap コマンドに投げることで一括decompileします。

find [ディレクトリ名] -name "*.class" | xargs javap

xargs を利用して javap に投げ込んでいく形にしました。
結果こんな形の出力が得られます。

Compiled from "hoge.java"
public class hoge extends hogeBase {
public hoge();
public boolean isHoge();
}
Compiled from "fuga.java"
public class fuga extends fugaBase {
public fuga();
public boolean isFuga();
}
...

javap コマンドのみだと細かい命令文までは出力されないので、細かい部分まで見たい場合は -c コマンドをつけてください。
(invokeとかldcといったレベルで出てくるのでぱっと見では難しかったです……)

まとめ

unzip と javap を組み合わせることによって、 .jar ファイルをdecompileすることができました。
いざというときには便利です。
そもそも .jar ファイルの中を見なければいけない状況に陥りたくない。

git logのaliasをつくりcommit logを見やすくする

概要

デフォルトの git log コマンドだとぱっと見でcommit logの流れがわかりづらい状況でした。
複数branchあったり、細かくcommitした結果logが深くなっていたりするとデフォルトのlogだと、状況を把握するのに時間がかかります。 デフォルトの git log コマンドだと表示がこんな形式に。
1画面に表示される5つのcommit情報しか表示されませんし、繋がりも見づらいため、把握するのが難しいです。

そこで、 git log にいろいろオプションをつけるaliasをつくり、logの出力を見やすくしました。
僕が使っているaliasではこんな感じの見た目に。

aliasの紹介

.gitconfig

[alias]
    gr = log --graph --all --oneline --decorate=auto --color

graph上にlogを出力するの意味で gr を当ててます。

--graph

ブランチの歴史をアスキーグラフで出力するようにするオプションです。

--all

リモート含めて全てのbranchの状態を表示するオプションです。

--oneline

出力内容を1行のシンプルなフォーマットに変更してくれるオプションです。
これのおかげでlogの流れがぱっと見で見やすくなります。

--decorate

branchの名称や、現在HEADがどこのbranchを指しているかなどの表示方法を変更するオプションです。
full auto no と3種類設定があり、特に何も指定していないと auto になります。

git log --decorate=auto

だとこんな感じの表示になり、

git log --decorate=no

だとこんな感じになります。

color

表示を色付きでカラフルにしてくれるオプションです。
しかし .gitconfig で

[color]
    ui = auto

を指定しておけばcolor出力できるものは全てしてくれるのでわざわざ指定する必要もないかも……?

まとめ

よく使うgitコマンドはaliasつくっておけば楽ができます。便利です。
上記で紹介した他、authorを表示するオプションとか、変更点がどのくらいあったかといった情報を表示するオプションとかいろいろとあるので、自分の環境に沿ったaliasをつくると幸せになると思います。

参考

Git - git-log Documentation

セイチョウジャーニーを読んだ

概要

技術書典から2週間近く経ち、自分自身の境遇に悩むことがありました。
なんとなく「成長してる感が欲しいな」とか、「何をするべきなんだろう」と考えることが多かったので、セイチョウジャーニーを購入するに至りました。
(半分くらい、てぃーびー【転職希望】 (@tbpgr) | Twitter さんとtwitterでやり取りしたから気になったという理由もあります)

ということでセイチョウジャーニーを読んだので読書感想文です。

第1章 ハイスコア・ボーイ

• 実体験に基づく対戦型格闘ゲームから学ぶポジティブフィードバックの話
• 人とのつながりがあると楽しさ・嬉しさは倍増する
• 義務感から学ぶのではなくて、自分から進んで楽しんで没頭できるものは成長が早いはず
• 何故上達に繋がったのか振り返ってみると良い

第2章 スゴクナイ・ジャーニー

• 認知の歪みは恐ろしい……現状の振り返りが正しく行えなくなる……たまには自分本位に考えてみることも大事
• 振り返りの際にダメだった点の方がよく見つかってしまうのは、人間そういうもの
• 自己肯定感を高められるようにする

• どうしても低くなるなら、高められるように行動を変える

• 振り返りの手法はいろいろある

  • KPTとかなぜなぜ分析とか高度マッピングとか

• こだわりを掘り下げれば自分の本当に求めているものが見えてくる

• 隣の芝は青いだけの状況で環境を変えようとしても同じ轍を踏むだけ

第3章 マヨイ・ジャーニー

不満や欲求は、理想の裏返し

• 1人で自分自身を変えるのはとても難しいこと

• 取り巻く環境が変われば自然と変化が起きる

  • webサービスを利用してそんな環境に身をおいてもいいんじゃないだろうか

• 周りの人が超出来る人だらけに見えることがよくある

• 自分自身が出来る人に見られる可能性だって十分にある
• ただそのためにはアウトプットをして見られる機会を増やさないといけない

第4章 言葉のセイチョウ・ジャーニー

• 言葉というものがどれだけ曖昧なものか

• ちょっと考えればわかることという考え方は危険

  • 他人に対して何かを教えるときこの思考のまま話していると大体伝わらない
  • ちょっとあとでやればいいやも同じように危険かもしれない……
  • 大体仕事でちょっとあとでやればいいやを行うとやらずに終わる

• 言葉を省略して話してしまう

  • ハイコンテキストの話？

日本は特にハイコンテキストの文化が強いようなので気をつけなければいけない。
ただし、ハイコンテキストは話す相手も正しくコンテキストを理解できているのならば説明する際にかかる時間、コストが低く済むから良いこともある。
状況に応じて言葉を使い分けられるようになれば成長したと言えるのかもしれない

第5章 行動のハードルを低くするジャーニー

• 成長につながる行動を過小評価していることがある
  • 行動すれば変化はついてくるもの
  • 行動そのものを目的にしたって良い。

無理に目標を立てようとして、なんだか現実的ではない
やたら厳しい制約を課している

身に覚えがあり過ぎて切なくなってきます……

• ふりかえりが反省会になってしまってはダメ

• 行動に変化をつけたいときは、環境/人/時間 に変化をつけてみるのが良い

付録 成長とはアンケート

とてもエモい付録でした。
他人の成長への考え方を見れる機会なんてなかなかないので、価値の高い付録に感じます。

私自身も成長に関してアンケートに沿って文章化しておけば、半年後くらいに成長を実感できる……かもしれないです。 (あとでやる)

まとめ

技術書典から少し経ち、早速コミュニティ参加とかしてみました。まだ1ヶ月足らずというところでしょうか。
ブログは書き続けられているし勉強会もいくつか参加できて、私自身の中でのハードルが下がっているのを感じます。 ちいさいことですが、積み重ねられて成長に繋がりそうな気がしています。

また別エントリーとして書きたいのですが、twitter転職が上手くいきそうです。
活動に対してのハードルを下げてくれた

• 完全SIer脱出マニュアル
• セイチョウ・ジャーニー

に感謝

ポモドーロテクニックとGitは相性が良い

最近仕事や趣味の作業時にポモドーロテクニックを利用して集中力を高めています。
我々エンジニアの使うGitととても相性が良いと感じたので布教記事です。

ポモドーロテクニックとは

1. 達成すべきタスクを1つ決める
2. タイマーで時間を指定する
3. タイマーが鳴るまで決めた1つのタスクに集中する。他のことは一切やらない。
4. タイマーが鳴ったら5〜10分休憩時間を取る
5. 1〜4の工程を繰り返す
6. 1〜4の工程を1ポモドーロとして、4ポモドーロ終えたら15〜30分程度長い休憩をとる

仕事の時間の使い方をフレームワーク的に決めることによって高い集中力を保とうとするテクニックです。
半強制的に休憩時間を挟むからペース配分が出来るという利点もあります。

私は

• 30分作業する
• 10分休憩
• 4ポモドーロこなしたら30分休憩

と緩めな設定にしてやっています。
スマートフォンは鞄にしまって、メッセンジャーの類も全て通知を切って行うのがコツです。
スマートウォッチをつけているので、腕時計でタイマーを動かしています。オススメです。

Gitと相性が良い話

Gitでcommitを積み込む際に、粒度が大きくなり過ぎることがよくあると思います。
そんなときにポモドーロテクニックを利用して、1ポモドーロでとりあえず1commit積み込むようにすると良い感じの粒度になります。
大体1ポモドーロ30分程度の作業量になるから、細かいタスク1つ分程度のcommitとなりcommit messageも書きやすくなるのです。

大体粒度が大きくなってしまったり、commit messageに2つ以上の要件が含まれて書きづらいときは、自分の中でも整理しきれていないことが多いので、調整として役立っています。

とはいえ30分で終わらないタスクもあるので、そういうときはとりあえずwip commitとして後でamendでまとめてしまいます。

まとめ

あれもこれもと考えが右往左往してしまう自分にとって、生産性を高める良いテクニックでした。
いろいろなこと考えてるときって頭が疲れるし、進捗も良くないのですよね……

現状ポモドーロを実践していて、8ポモドーロくらいやると集中力の限界がきます。
自分の限界も把握しつつ仕事進められるようになれば効率上げられるかなあと考える次第です。

SIer/SESに未来を感じない

hotchemi.hateblo.jp

Twitterでこの記事が回ってきて読みました。
今現在SESに身を置いているので共感できる部分が多かったです。

読み終わった後によくみてみたら書かれたのが2013年。
5年も前の記事でした。
5年も経っているのに何も状況が変わっていないSIer/SES業界に闇を感じたのでぽえむを書きます。

経歴

この辺りの話って経歴とか立場によるバイアスがかなり強いと思うので、ざっくり経歴を書きます。

• 現在25歳
• 情報系大学既卒
• モバイルゲーム会社に早めに内定をもらい、学部4年から働き始めて、2年半程度
• モバイルゲーム会社を退職し、現在SES企業

SIer/SESの良くない点

整った文章にするのが難しいので、箇条書きで羅列していきます。
ちなみに私は今N●●の現場でお仕事をしています。

技術力のある人が少ない

現在既存システムの改修という形で仕事をしているのですが、使われているフレームワークとかコードの構成がどうとか把握できている人間がいません。
システムの歴史が古い影響もあるので、仕方がない点もあると思うのですが、現場で書かれているコードを見ると、
そこら中にあるtypo / 深いネスト / ずれるインデント / ファイルの中にタブとスペースが混在 / 1つのメソッドが100行超え / 実行されないコード / 共通モジュールと言う名の神クラス / ドキュメントは書かれているものの間違っている / 使われていないドキュメント / コメントが信じられない / 役に立たないコメント(// xxにyy代入するみたいな)
と巷でクソコードと呼ばれるものの役満をいっている感じでした。

社員の人に 「この会社で向上心を持っている人なんていない。とりあえず動けば良い」 と明言されて僕の心は崩壊しました。
読書会とかしようと提案しても乗ってくる人はいません。
反応もらえたとしても「できたらいいよね〜」だけです。

IT技術を利用していない

たしかにプログラミングして、アプリケーション作って、それが世の中で使われているのですが、何かIT技術というものを勘違いしているような気がしてなりません。

例えばテストについて

エンドユーザーとなるお客様がいて納品する形式になるので、テスト、もとい試験と呼ばれるものは重要です。
ですが、なぜ手作業で試験を行うのでしょうか……
しかも試験書と呼ばれるものは紙で出てきます。 単体試験から、結合試験まで紙とペンを利用して行われます。
ネット上で噂には聞いていましたが、実際に目にすると目眩がする状況でした。
品質を高めるため、バグを減らすためのテストではなく、カバレッジやエビデンスを出すためだけにテストが行われています。
目的と手段をはき違えてしまっている。そんな印象を受けました。

嫌われる自動化

私はプログラミングにおいて自動化に著しい興味関心を覚えています。
ですが、SIer/SES業界では自動化は好まれていないようです。
人月という制度によって自動化して効率化してしまうと、SES会社が困るという話もありますし、
そもそも自動化という概念が頭から抜け落ちている人が多いように感じてしまいます。

手作業バージョン管理

20181013第一版.xlsx みたいなファイル命名で管理されてます。
gitなんて使われません。svnすら怪しいです。
なぜ使われないのか聞いてみたのですが、
「社員に覚えさせるコストが高いから」「現状の形でなんとかなってる」「セキュリティ上の問題で使えない」
といった言葉が返ってきました。
些細な抵抗として、私はローカルでgitを立ち上げて自分の作業だけ管理してます。
頭で覚える必要がないから楽です。

情報共有が行われない

まだ何故なのかまでは把握できていないのですが、情報共有が一切行われません。
誰が何の仕事をしているのか、どの仕事がいつ終わるのか、xxのことは誰に聞けばいいのか
そういった情報が全く出回らないのです。
もちろんSlackのような社内チャットツールのようなものも存在しないので、情報共有する場が整っていないという点もあります。

何故5年前から何も変わっていないのか

ここまでほぼ愚痴のような形でSIer/SESのダメな点を書いてきましたが、「何故ダメだとわかっているのに変わらないのか」
ここに関して気づいたことを書きます。

変化を嫌う体質

SIer/SESは比較的古く、大きい企業が多いようです。
そのためか変化を嫌う傾向がつよく感じます。
たとえ改善活動といっても何かをするには許可を取らなければいけない仕組みが出来上がってしまっています。
そしてその許可は降りないか、降りるとしても長い時間がかかります。

個人的には、なにか問題が起きるとしたら、そもそも問題が起きないようにする のも大事なのですが、 それ以上に 問題が起きた時にカバーできる仕組みや力をつける の方が大事だと思っています。

「許可を求めるな謝罪せよ。」

この精神を忘れずに生きていきたい。

向上心がない

前項で書いた通り、勉強熱心な人間がほぼいないようです。
向上心がなかったら改善も発生しないので、何も変わらないでしょう。

何故向上心が生まれないのか考えてみましたが、良くも悪くも 仕組みが出来上がってしまっているから このように感じます。
例えば人月計算のSES企業の場合、極端な話何もしなくてもその場にいれば賃金が発生します。
向上心を持って勉強しなくても生活できてしまうから焦りといったものも発生しないのです。
これが悪いことだとは言いませんが、私は居心地悪く感じてしまいました。

さいごに

ほぼほぼ愚痴みたいな形でぽえむを書いてしまいましたが、この業界があること自体は悪いとは思っていません。
未経験に対して広く窓口を開けているのも業界全体の人口を増やすのに繋がっているだろうし、悪いことだけではないはずです。
(未経験が給料安くて……みたいな話はまた別として)
ただただ改善や変化といったことを嫌う傾向があるといった点だけ残念でなりません。

最初にあげた記事が、5年前の記事。
そして記事内で10年前から何も変わっていないと言われているため15年になります。
15年経って変化がないというのは、そういうことでしょう。

まだ2ヶ月程度しか業界に身を置いてませんが、エンジニアとしてこの業界に慣れてしまっては今後が危ういと感じたため、転職活動をはじめました。
すぐに転職できるとは思っていないので、いろいろインプット/アウトプットしつつ、自分の成長を促してより良い環境を求めています。