はじめに

RedHat Enterprise Linux 6.7 で、Proxy を使いたかったので、Nginx を導入する。
いきなり yum install しようとして、パッケージが見つからないって怒られたので、調べた結果の備忘録。

環境

$ more /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)

yum install で失敗

Redhat 公式のリポジトリにないにない様子

$ sudo yum install nginx
No package nginx available.

nginx 公式サイトにリポジトリ発見

http://nginx.org/en/linux_packages.html#stable

Redhat 5,6,7/ CentOS 5,6,7 があるので、Redhat 6 のリポジトリを使用する。

$ sudo rpm -ivh http://nginx.org/packages/rhel/6/noarch/RPMS/nginx-release-rhel-6-0.el6.ngx.noarch.rpm

(注意: URL が変わる可能性があるから、公式サイトから直接コピーした方が良い)

(蛇足) このとき rpm の proxy でハマったから以下のページを参考に解決

http://qiita.com/Ki4mTaria/items/d10f3d562d02a0a4ded4

yum install で成功

$ sudo yum install nginx

終わりに

単純にリポジトリの追加だけで、完了した。
次は、proxy の設定する予定。

はじめに

git のリポジトリを立てるために、GitBucket を使ってみる。
RedHad Enterprise に入れる手順を残しておく。

環境

$ more /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)

インストール手順

Java のインストール

ここはサクっと

$ yum install java-1.7.0-openjdk-devel.x86_64
.
.
(完了)
$ java -version
java version "1.7.0_85"
OpenJDK Runtime Environment (rhel-2.6.1.3.el6_7-x86_64 u85-b01)
OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode)

GitBucket をダウンロード

https://github.com/takezoe/gitbucket
公式サイトのリリースページから最新版を取ってくる。今だと 3.5 。

$ wget https://github.com/takezoe/gitbucket/releases/download/3.5/gitbucket.war

動くかどうか試してみる

$ java -jar gitbucket.war

これで、ポート8080 で接続できたら成功

GitBucket をデーモン化する

gitbucket 公式で、redhat 用のスクリプトがあるので、これを使用する。

$ cd /etc/rc.d/init.d/
$ wget https://raw.githubusercontent.com/takezoe/gitbucket/master/contrib/linux/redhat/gitbucket.init

修正する箇所は、以下の部分と実行ユーザ名あたり。
GITBUCKET_HOME はリポジトリなどを配置する場所。
GITBUCKET_WAR_FILE は文字通り war ファイルを配置する場所。

# Default values
GITBUCKET_HOME=/var/lib/gitbucket
GITBUCKET_WAR_FILE=/usr/share/gitbucket/lib/gitbucket.war

設定が終わったら、スクリプトを動かしてみる。

$ /etc/rc.d/init.d/gitbucket start
Starting GitBucket server:                                 [  OK  ]

FAILED になった時は、log を見て設定を見直す。

終わりに

簡単に github クローンの gitbucket が動かせることは、すごい。
あとは、gitbucket のバックアップ方法などを調べる。

はじめに

WEBrick を Nginx の reverse proxy のバックエンドにしたくて、サービス化するためのスクリプトを書いた

動作環境

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)
# ruby --version
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux]
# rails -v
Rails 4.2.3
# ls
redmine-3.1.0.tar.gz

スクリプト

実際のスクリプトは、以下の Gist を確認して欲しい。
https://gist.github.com/takuyaohashi/c49117930473487dc020

使い方

# set rails application path
APPLICATION_ROOT="/path/to/webrick/dir"

# add path to bundle
export PATH=/usr/local/bin/:$PATH

# set configuration
PORT="3000"
BINDING_IP="0.0.0.0"
ENVIRONMENT="production"
RAILS_RELATIVE_URL_ROOT="/hoge/hoge"

基本的に上記設定を個々の環境にあわせて変更してもらえれば、使用できるはず。
特に説明は不要かと思いますが、1点だけ注意。
RAILS_RELATIVE_URL_ROOT を使う時は、config.ru を下記のような修正が必要。

4c4,14
< run WEBrickApp::Application
---
> if ENV['RAILS_RELATIVE_URL_ROOT']
>   map ENV['RAILS_RELATIVE_URL_ROOT'] do
>     run WEBrickApp::Application
>   end
> else
>   run WEBrickApp::Application
> end

(参考URL: http://chroju89.hatenablog.jp/entry/2015/01/05/222205)

サービス化

以下のコマンドでサービス化を行う

# chkconfig --add webrick
# chkconfig webrick on

おわりに

使用するユーザも多くないし、レスポンスもそんなに気にならないと思うから、WEBrick でサーバを立ててみた。
パフォーマンスが気になってきたら、Unicorn とか他の手段を考える。

はじめに

前にWord でレポートを書いていたけど、目に見えない機能というか挙動にイライラしてた。。Markdown だったら全て明示的にマークアップできるので思い通りに書けるのではないかと思いやってみた。

事前準備

下記ツールのインストールする。僕は以下のバージョンで試した。

• rake, version 10.0.3
• ImageMagick 6.6.9-7
• pandoc 1.9.1.1

テンプレート

github にテンプレートをアップした。
https://github.com/takuyaohashi/report_template

Rakefile の部分だけ抜粋すると、以下のようになる。
枠組みだけ、report.tex で作って、その中の section を Markdown で記述して、PDF 化している。
画像も PNG から EPS ファイルに変換して挿入している。

##
## Rakefile for Building Report from Rakefile
##
require 'rake/clean'

REPORT_FILE = "report.pdf"
MD_FILES = FileList["src/*.md"].exclude("README.md")
TEX_FILES = MD_FILES.ext(".tex")

CLOBBER.include("*.pdf")
CLEAN.include(TEX_FILES)
CLEAN.include("*.dvi", "*.log", "*.aux")

task :default => [:dvi2pdf]

task :dvi2pdf => [:tex2dvi] do
  sh "dvipdfmx", REPORT_FILE.ext(".dvi")
end

task :tex2dvi => [:md2tex] do
  sh "platex", REPORT_FILE.ext(".tex")
  sh "platex", REPORT_FILE.ext(".tex")
end

task :md2tex => TEX_FILES

# *.md -> *.tex 変換ルール
rule ".tex" => ".md" do |t|
  sh "pandoc", "-o", t.name, t.source
end

良かったこと

文章の記述に集中できる

Word だといろいろ装飾が邪魔してイライラしていたけど、Markdown なら簡単にマークアップしていくだけで見やすく、構造の変更がしやすい。
デザインと文章が分かれているので、後からでもデザインが変更できる。

思い通りに行かなかったこと

画像の挿入

下記の記述方法で画像が挿入できるけど、これ以上の細かい指定ができず、右詰めとかサイズ変更ができない。

![hoge](hoge.eps)

\begin{figure}[htbp]
\centering
\includegraphics{hoge.eps}
\caption{hoge}
\end{figure}

画像へのリンク

tex では、label と ref でリンクが張れるが、Markdown にそのような記述がないからリンクが張れない。
文章中で画像を参照したいときに Markdwon 内で簡潔しない。変換後の tex を修正するしかない。

テーブルの作成

テーブルを使おうと思ったが、うまくtexがコンパイルできなかった。下のページを参考にしてみたが、うまくいかなかった。
仕方なく tex をそのまま書いた。
pandocでmarkdownをtexに変換するとtableがおかしくなる件

おわりに

Word よりイライラは少ないが、画像周りの処理がうまくもっと行けば快適にレポートがかけると思う。
もし記事内で僕ができなかったことで、やり方を知っている人は教えてください･･･

はじめに

ARM が純正で ARMv8 アーキテクチャのシミュレータを配布していることを知ったので、さっそく動かしてみた。

動作確認環境

• Ubuntu 12.04.4 LTS 64bit 版

シミュレータのダウンロード

公式サイト からダウンロードできるが、ユーザ登録が必要。それが済むと、ARM V8 Foundation Platform (Linux) というところに Download ボタンがあるので、そこからダウンロードできる。このときに住所とか入力フォームが出てくるが、必須ではないのでそのまま次に進める。

実行してみる

展開すると Foundation_Platformpkg というディレクトリができる。

内容はこんな感じ

$ tree
Foundation_Platformpkg
├── doc
│   ├── DUI0677E_foundation_platform_ug.pdf
│   └── FoundationPlatform_Readme.txt
├── examples
│   ├── foundation-platform.dts
│   ├── hello.axf
│   ├── hello.c
│   └── Makefile
├── LES-PRE-20164-V5_0_-_Foundation_Platform.txt
└── models
    └── Linux64_GCC-4.1
        ├── Foundation_Platform
        ├── libarmctmodel.so
        └── libMAXCOREInitSimulationEngine.so.2

4 directories, 10 files

example に ELF があることが確認できる。
中身は、printf するだけ。

#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("Hello, 64-bit world!\n");
    return 0;
}

Foundation_Platformpkg/models/Linux64_GCC-4.1/Foundation_Platform がシミュレータ本体っぽいので、これを実行してみる。

$ ./Foundation_Platform --image=../../examples/hello.axf                                                                                                                                       
terminal_0: Listening for serial connection on port 5000
terminal_1: Listening for serial connection on port 5001
terminal_2: Listening for serial connection on port 5002
terminal_3: Listening for serial connection on port 5003
Simulation is started
Hello, 64-bit world!

期待通り動いていそう。シリアルがどうとか出力されるので、UART とかで出力は出来そう。

おわりに

今回はとりあえず動かすところだけだが、これだけでは全く面白くないので、自分で作ったプログラムを動かしたい。armcc は有償なので、gcc か llvm で出来ればよいかなと思っている。

はじめに

Start Developing iOS Apps (Swift)

Swift で iOS App を作るチュートリアルがあったので、やってみることにしました。
周りに iOS App を作っている人がいないので、アドバイスくれる人がいないのでこういうのがあるととても助かります。

github にコードを置いてあります。
https://github.com/takuyaohashi/FoodTracker

私について

• 普段は組み込みソフトウェア屋さんで、C/C++ をメインに使っている
• iOS/Android アプリを書いたことはない
• 6年くらい前に PHP でショッピングサイトを作っていたが、もう覚えていない
• 普段のエディタは Emacs
• Swift の文法は 詳細 Swift で簡単に眺めた程度。

こんなバックグラウンドの人の視点でチュートリアルをやってみた感想を書きます。

動作確認環境

• OSX El Capitan 10.11.4
• Xcode 7.3

チュートリアルに書いてあること

Storyboard を使った開発

Object の配置、ソースコードとの紐付け、複数 Storyboard との連携、Navigation Controller の使用など Storyboard の基本的な使い方を広く書いてあります。
Apple は、Storyboard を使って欲しいっていう意思が伝わってきました。

個人的にはもっと AudoLayout などのデザインの配置とかをもっと詳しく書いて欲しかったなって思います。
たぶんプログラマだから、デザインについてピンと来ないって言うのもあるのかもしれませんが･･･

Optional 型の説明

ソースコードに Optional 型が出てくる度になんでここはこうなるのかっていう説明がされるので、分かりやすかったです。
私の理解では、nil になる可能性があるところは、? をつけて、nil だと致命的な場合は ! をつけるっていう理解をしました。(ホントはもっと違うのかもしれないですけど･･･)

Xcode の便利な使い方

ショートカットキーや、// MARK: つけることでそのマーカーに一発で飛べるようになる、とか Xcode の使い方もときどき説明してくれます。
キーバインドが emacs ライクなのはとてもありがたかったですね(OSX 全般的にそうですが)。もっと emacs に近づけたいところはあります。Ctrl-m とか。

データの永続化について

NSObject/NSCoding を用いたデータの永続化を行っています。
ユーザが投稿したデータはどこかに保存しないと消えてしまうので、NSObject/NSCoding を使っていますが、実際のサービスだとサーバに情報をアップしたり、SQL に保存したりするのだろうなあと思って読んでました。

単体試験について

Meal.swift という食事を表すクラスがあって、チュートリアルでそのクラスのイニシャライザの単体試験を記述しています。
単体試験の枠組みが Xcode には入っているので、それの説明が簡単にしてあります。
CI とかでコミットされる度に自動的に単体試験を実行できるようにしたいですね。

TravisCI でビルドチェックだけは行っています。色々試したみたのですが、TravisCI で単体試験の実施方法が分かりませんでした･･･
https://github.com/takuyaohashi/FoodTracker/blob/master/.travis.yml

チュートリアルに書いてないこと

Storyboard を使わない開発

アプリを作ってみようと思ってネットで調べていると、Storyboard を使わないっていう人・記事がチラホラ見かけます。
複数人開発がしにくい とか色々理由はあるらしいです。
私は普段 C/C++ をメインに開発しているので、StoryBoard を使われるとソースコードのつながりが直感的に分からないなって感じました。
でも、Apple としては、Storyboard の使用を推奨しているみたいだし、個人で作る分には問題ないのかなって思って、まずは Storyboard を使って開発してみようと思っています。

外部のサービスとの連携

Apple のチュートリアルだから当然なのかもしれないけど、Twitter や Facebook などの外部サービスとの連携については一切書いてありません。
あと、Cocoa Pods についても書いていません。

CoreData を使った開発

プロジェクトを最初に作るときに、「Use Core Data」のチェックボックスがあるけど、そこはチェックしないでアプリを作るので、CoreData を使用する方法などは書いてありません。
永続化する方法の1つだという認識です。どういう方法でデータを永続化させるかはアプリの特性によるんでしょうね。

おわりに

このチュートリアルをやっただけで、何でもアプリを作れるぜ！とはならないけど、大まかな流れをつかむことができます。
「チュートリアルに書いてないこと」にも記述しましたが、外部サービスとかの使い方とかには一切触れてないので、手っ取り早くアプリを作りたいぜっていう人には歯痒いかもしれません。
随所に Apple 的にはこうしてほしいっていうのがあって、思想を垣間見ることができるので、時間がある人はざっとやってみることがいいかもしれません。

進めたとしては、チュートリアルやりながら、章とか節ごとに git で commit することをオススメします。
写経をミスって訳分からなくなった時に前の状態に戻れるし、ここのソースをこうやったらどういう挙動になるんだろうっていうのが気軽に試せます。

何かアプリを作ったらまたその感想も書こうと思っています。

追記

本格的にアプリを作る準備を始めました。
具体的には iOS App 100本ノックというのを始めて、自分が作りたいアプリで使う技術を使ってみるようにしました。github にもコードが上がってるので、ご指導していただけると助かります。また、最近 swift で iOS App を作り始めた人がいたら、教えあえたあら良いなと思っています。

はじめに

この記事はFlutter Advent Calendar 2019 7日目の記事です。

前日は @kikuchyさんの自動コード生成を駆使してFlutter開発を楽にするでした。知らないことだらけだったので、勉強になりました。

どうも、たくチャレです。

7日目はpub.devに自分が作ったパッケージを登録する方法を紹介します。

ただ登録するだけだったら一瞬で終わってしまうので、

• 公式オススメのファイル構成の紹介
• パッケージの自動テスト・カバレッジ取得
• verified publisher のなり方

も合わせて紹介します。

私は先日非常にシンプルなdot_pagination_swiperを登録してみました。画面の下部にドットのページネーションを実現するだけのパッケージです。これを登録した時の流れを紹介します。

pub.dev とは

https://pub.dev/

Flutterでアプリを作ってる人に説明は不要かと思いますが、pub.devはDartの公式パッケージリポジトリです。FlutterやWeb向けのDartのパッケージを一覧・検索・登録を行うことができます。

pub.devで面白いと思ったのは、パッケージがPopularity、Helth、Maintenanceの3項目をもとにスコアリングされていることです。他の言語・プラットフォームのパッケージリポジトリは知らないのですが、こういう目安があるとユーザがパッケージを選ぶ基準になりますね。

パッケージ登録の流れ

流れは以下の通りです。

1. パッケージ作成 (flutter create --template=package hello)
2. パブリッシュの dry run (flutter publish --dry-run)
3. エラーがなければパブリッシュ (flutter publish)

iOS/Android のネイティブの機能を使う必要がある場合は、--template=pluginを指定してください。パッケージの作成はAndroid Studio などGUIで行えますが、publishする方法は分かりません…

パッケージ登録の流れ自体は簡単ですが、1. のパッケージ作成が一番大変でしょうね…笑

初めてパブリッシュした時に以下のような文章が出てきます。yを入力して、表示してあるURLをブラウザにコピペしてAllow accessを押してください。Google アカウントに紐づいてパブリッシュされます。

Looks great! Are you ready to upload your package (y/n)? y

Pub needs your authorization to upload packages on your behalf.
In a web browser, go to https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=force&response_type=code&client_id=xxxxxxx.email
Then click "Allow access".

現在のコマンドラインツールの仕様上、後述するverified publisherにいきなりパブリッシュすることはできず、一度自分の Google アカウントに紐づけてパブリッシュした後にverified publisherに移管する形になります。こちらのNoteを参照してください。一度移管してしまえば、更新は直接行えます。

ファイル構成

公式ドキュメントからの引用ですが、以下はenchiladaという名のパッケージのファイル構成例です。

enchilada/
  .dart_tool/ *
  .packages *
  pubspec.yaml
  pubspec.lock **
  LICENSE
  README.md
  CHANGELOG.md
  benchmark/
    make_lunch.dart
  bin/
    enchilada
  doc/
    api/ *
    getting_started.md
  example/
    main.dart
  lib/
    enchilada.dart
    tortilla.dart
    guacamole.css
    src/
      beans.dart
      queso.dart
  test/
    enchilada_test.dart
    tortilla_test.dart
  tool/
    generate_docs.dart
  web/
    index.html
    main.dart
    style.css

*がついているファイルは自動生成されるファイルなので、VCS には入れないでください。
**のpubspec.lockはアプリケーション以外では VCS に入れないでください。

上記ファイル全てが必要なわけではなく、pubspec.yaml、LICENSE、README.md、CHANGELOG.md、lib/*があればパッケージとして成立します。

それぞれを簡単に説明します。

pubspec.yaml

パッケージの情報を記載するためのファイルです。
flutter createした後description、author、homepageを追加すれば OK です。

更に詳しい情報はこちらを参照してください。

LICENSE

ライセンスの定義をしましょう。Flutter本体がBSD-3-Clauseを採用してるので、私もそうしてます。自身のポリシーに合わせてもらえれば良いと思います。

flutter createした直後はLICENSEに何も書かれていないのでちゃんと忘れずに書きましょう。私は忘れました。

README.md

GitHubなどでもトップページに表示される説明文ですね。pub.devでもパッケージのトップページに表示されるので、いろんな人に使ってもらいたい場合しっかり書きましょう。

CHANGELOG.md

pub.devのパッケージのChangelogタブに表示されます。ユーザが変更点を簡潔に知るための手段なのでしっかり書きましょう。

lib/*

パッケージのソースコード本体です。

パッケージの自動テスト・カバレッジ取得

ちゃんとビルドできるか、どれくらいテストカバレッジがあるかもユーザがパッケージを選ぶ指標の一つになると思います。ステータスバッジあるとかっこいいですしね！

テストの書き方に関しては、3日目の @chooyan_engさんがWidget テストの「あれ、これどうやるんだろう？」集を書いてくれていますので、みんな要チェックです！

ここではGitHub Actionsを使った自動テストとカバレッジ取得の方法を紹介します。

設定ファイルをバーンと書いてしまうと次のようになります。flutterコマンドのversionとchannelを指定することができます。カバレッジ自体はflutter test --coverageで取れますが、それでは見にくいのでCodeCovで可視化してあげます。

name:Teston:[push]jobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v1-uses:takuyaohashi/setup-flutter@v1with:flutter-version:'latest'channel:stable-name:install dependenciesrun:flutter pub get-name:analyzerun:flutter analyze-name:testrun:flutter test --coverage-uses:codecov/codecov-action@v1with:token:${{ secrets.CODECOV_TOKEN }}

複数バージョンで行いたい場合以下のように記述できます。テスト部分以外は割愛。

jobs:test:runs-on:ubuntu-lateststrategy:matrix:flutter:['latest','v1.9.1+hotfix.6']steps:-uses:actions/checkout@v1-uses:takuyaohashi/setup-flutter@v1with:flutter-version:${{ matrix.flutter }}channel:'stable'-name:testrun:flutter test

詳しくは下記ブログに書いてあるので参照してください。

• GitHub Actions で自動テストを行う方法
• GitHub Actions でテストカバレッジを取得する

ちなみにflutterコマンドを使えるようにするアクション(takuyaohashi/setup-flutter)は自作しました。ああしたい、こうしたいがあれば気軽にissue/PRをください。

verified publisher のなり方

verified publisherになるとcloud_firebase の右にあるようなバッジがつきます。なんかかっこいいですね！！

verified publisherになる前提として自身が管理しているドメインを持っていることが必須です。私の場合takuchalle.devですね。ドメインさえもっていれば、パッケージを一つも登録していなくてもverified publisherになることができます。それでいいのかって感じですけど笑

まだ何もないけど、バッジをゲットした。 #flutter#pubpic.twitter.com/KuDfv3JCmi

— たくチャレ@めざせポケモンマスター (@takuchalle) November 20, 2019

手順としては簡単で、右上のアカウントのところのCreate publisherからポチポチ押していけばOKです。pub.dev で verified publisher になる方法に詳しい手順が書いてあるので参照してください。

まとめ

pub.devに自分のパッケージを登録する方法とそれに付随する周辺情報を紹介しました。

人のソースコードを読むのが好きなので、いろんな人がどんどんパッケージ化してオープンにしてノウハウを広めていって欲しくてこんな記事を書きました。ソースコードを読むためだけだったらGitHubを覗きに行けばいいのですが、良いパッケージがあれば自分のアプリに組み込んで楽をしたいし笑

もっとFlutterの勉強して私も貢献できるように頑張ります。

Flutterはフレームワークの良さもさることながら、pub.devなどのエコシステムもちゃんとしてるのが良いですね。Dartも普段C言語をメインに使ってる私からすると機能豊富だし、文末もセミコロンも気になりません。

明日は @mjhd-devlionさんのflutter webに関する記事です。楽しみですね！