サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
naokirin.hatenablog.com
基本的に継続的な開発を行っていく上で、CI/CDは避けて通れなくなっています。CI/CDといえば、これまでも様々なツールやサービスがありました。 クラウドの発展やインフラ環境の変化などもあり、個々の特性を生かした機能やサポートなどを持つツールやサービスが生まれてきています。 OSSで基本的に自身で環境を構築する汎用ツール:Jenkinsなど CI/CD専用のSaaS:Circle CI、Travis CI、AWS Codeシリーズ、Google Cloud DevOps、GitHub Actionsなど クラウドやKubernetes環境向けのCD:Spinnakerなど アプリケーション実行環境とCDがセットになったPaaS:GAE、AWS Beanstalkなど 一方、この各ツールやサービス間で移行することになると、複雑になりがちな設定の書き換えや、特定ツールのサポートやプラグインに乗
Rails では様々な機能を使って、共通化や抽象化、シンプルなコードへの書き換えなどを行えるようになっています。今回はモデルに焦点を絞り、それらをまとめていきたいと思います。また、整理を始める前に気をつけるべきことをまとめておこうと思います。 Rails5 以降をメインとしていますが、概ね Rails4 でも同じであることが多いのではないかと思います。 おもに自分向けの情報整理です。 コールバック 整理する前に コールバックはシンプルな機能に絞る テストでも走ることを考慮しておく コールバックをクラスに分離する バリデーション EachValidator、PresenceValidator、UniquenessValidator Validatorとvalidates_with 値オブジェクト 値オブジェクトとcomposed_of ActiveSupport::Concern と Mix
もう使い古されたネタという感じですが、Railsを使わずとも ActiveSupport だけを利用してRubyのコードを書くことは結構多いのではないでしょうか。 blank? , present? であったり、 pluralize や try 、 1.year.ago のような呼び出しなど、ヘルパーメソッドはRubyの標準ライブラリだけではなかなかスッキリとかけないところに手が届き、非常に重宝します。また ActiveSupport::Concern は Mix-in をする際に非常に便利です。 が、今回はRailsの ActiveRecord インスタンスのように扱えるようになる ActiveModel::Model に注目してみることにしました。 ちなみに、ActiveSupport の Core Extensions については、以下を参考にするのが良いかと思います。 Active
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで 作者: 市谷聡啓,新井剛出版社/メーカー: 翔泳社発売日: 2018/02/15メディア: Kindle版この商品を含むブログを見る カイゼン・ジャーニーを読み終えました。 というわけで読後の感想を書いていきます。 今回は何のプラクティスが紹介されているとかではなく、全体的な内容について書いていこうと思います。 単にアジャイルをやるのが、この本の本質ではない 読みながら感じていたことの1つがこれでした。アジャイルという以上に「カイゼン」というところが大きいと思います。 本の最初の方に出てくる言葉 「それで、あなたは何をしている人なんですか?」 これに対してどう答えられるのか。改善したいことがあるということはそこに問題があって、問題があるということはプロジェクトにおいてより早くより安全により高い価値を提供できないと
複雑化しやすいマイクロサービス間の連携の解決について気になっているところでlinkerdについて知ったので少し調べてみました。 ただ、思ったより日本語の情報は無いですね。。。 大規模なサービス連携でなければ、Consulなどでのサービスディスカバリ単体があれば十分であることが多くて、導入までに至らないからでしょうか。 もとのドキュメントもしっかりしており、GitHub等を見る限りでも必要な機能も揃っている印象で日本語情報なしでもある程度は簡単にできるのでは?とは感じました。 linkerdやConsulなどのサービスディスカバリやルーティングの支援ツールが複数出てきており、これらを導入するほうが早いか、大規模化・複雑化しないことを前提に取り入れずに進めるかは判断の別れるところになりそうです。 linkerdとは linkerdは分散型のアプリケーション間の連携を支援するオープンソースのツー
最近、UnityでPlayable APIというものを調べる機会がありました。 その際にそのPlayableの木構造をUnity上で表示できるEditor拡張としてPlayableGraphVisualizerというものがあると知ったので軽く見ていて、「Reingold Tilford」というものが出てきて調べていたので、それをまとめておきます。 (ちなみに、PlayableGraphVisualizer - https://bitbucket.org/Unity-Technologies/playablegraphvisualizer) 結論としてはこの「Reingold Tilford」は「Reingold Tilford アルゴリズム」と呼ばれるもので、木構造を階層的に“きれいに”表示するためのアルゴリズムです。木構造のグラフ表示の機能を持ったJavascriptのライブラリなどでは
今日は非常に初歩的なTips的な話です。 Unityのドキュメントをちゃんと読んでれば知ってるくらいの知識、ということで。 Unityでゲームを開発していると(というよりはゲームを開発しているとよくあるとは思うのですが)、どうもダメージを食らったときにもっさりしているから軽くしよう、とかいう話が上がったりします。 このときにProfilerやスクリプトにログを埋め込んだりであれやこれやと調べたりするわけですが、Profiler上で表示される粒度が大きすぎて結局どこが問題か調べきれないといったことがあります。 この際に、Unityには便利な機能として、Profiler.BegineSample()/EndSample()があります。 実際にこれらを使うとどのようになるかです。 まずはこのようなサンプルスクリプトを用意しました。 using UnityEngine; using System.
最近、インデックスについて調べることがあったので、忘れないうちに出来る限り情報を残しておこうと思います。 ちなみにMySQLのバージョンは5.5および5.6の情報を元にしています。 InnoDBにおけるインデックス インデックスの構造 B+Treeインデックス InnoDBではデータはテーブルスペースと呼ばれる領域にあります。さらにこのテーブルスペースはページ(ブロック)単位で管理されており、このページ単位でB+Treeが構成されるようになっています。つまりI/Oの単位はページ単位になっている、ということです。 クラスタインデックスとセカンダリインデックス InnoDBではテーブルの検索や操作に使われるインデックスとして2種類のインデックスが存在します。それはクラスタインデックス(Clustered index)とセカンダリインデックス(Secondary Index)です。 クラスタイン
いろいろClojureを調べていたところ出くわした"->"というマクロが気になったのでリファレンスを見てなんとなく理解した気がするので書いておきます。 アロー(->)なマクロさん 現代的にしようという意図はありつつも、Lisp道をひた走るClojureさん。 連鎖的な関数呼び出しでよくあるのはやはりS式です。 (println (- (int 2.1) 1)) ; => 1 この結果は1が表示されるというものです。 ですが、"->"マクロは同じことを (-> 2.1 int (- 1) println) ; => 1 このような書き方で実現できるようになります。 つまり、最初に受け取った引数を第2引数で受け取った関数の第1引数に、そしてその結果を第3引数で受け取った関数の第1引数に…といった形で処理していきます。S式の例と見比べれば分かりやすいと思います。 ダブルアロー(->>)なマクロさ
前回はGitを使う上で絶対に必要なコマンド(+オプション)について書いてみました。 実際には他にも必要なコマンドはたくさんありますが、今回はそのうちでも「見る」ということに焦点を当てたコマンドをまとめてみようと思います。 git status (現在の状態を見る) git diff (差分を見る) git ls-files (管理しているファイルを見る) git shortlog (軽くコミットログを見る) git log (コミットログを見る) git reflog (HEADの遷移を見る) git show (コミットの詳細を見る) git grep (ワークツリーのファイルを検索する) git blame (ファイル内の行ごとの最終更新を見る) git status (現在の状態を見る) まずは現状を知ることから。 git statusとすると、現在のブランチとコミットされていない、
今回はweak_ptr。 weak_ptrは弱参照の概念のためのスマートポインタです。 shared_ptrでは循環参照の問題を解決できません。 #include <iostream> #include <memory> class Sample { public: Sample() {} ~Sample() {} std::shared_ptr<Sample> ptr; }; int main() { std::shared_ptr<Sample> p1(new Sample); std::shared_ptr<Sample> p2(new Sample); p1->ptr = p2; p2->ptr = p1; return 0; } // 解放されない しかし、弱参照であるweak_ptrは参照カウントを行わないため、参照がある無しに関わらずスコープを抜けるとインスタンスを解放します
今回はリモートリポジトリを操作するコマンドをまとめます。 リモートリポジトリの操作は同じような操作をする際にもローカルリポジトリとは異なっていたり、お作法としてしてはいけないこともあります。 そういう点は気をつけて使ってみましょう。 git clone (リポジトリの複製を行う) git remote (リモートリポジトリを見る) git push (リモートリポジトリに送信する) git pull (リモートリポジトリの変更を取り込む) git fetch (リモートリポジトリの変更を取得する) git clone (リポジトリの複製を行う) リポジトリの複製を行います。 それだけです。 --bare git init で説明したbareリポジトリとしてリポジトリを複製します。 git remote (リモートリポジトリを見る) 登録されたリモートリポジトリを見たりする際に使います。 も
#include <iostream> #include <vector> #include <memory> using namespace std; class Sample { public: // 普通のctor Sample( int x ) { vec = unique_ptr<vector<int> >( new vector<int>() ); vec->push_back( x ); } // Move ctor Sample( Sample && r ) { // ちなみに、ただのcopy ctorでmoveなんてしたら大変なことになるので注意 vec = move( r.vec ); } // dtorは空。unique_ptr便利!! ~Sample(){} // Movable substitution operator Sample& operator =( S
OCamlを使っている皆さん。テストコードは書きますよね。 そこでOUnitの登場です。 OUnitはOCamlのユニットテスティングフレームワークです。OSSなどでも良く使われています。 …が、OUnitは結構冗長、というよりテスト自体の本質が見えにくくなることがあります。 そのため、結構シンプルなテスト以外が行われていないOSSもある気がします。(強い静的型付けなのでそれでもバグは少ないのでしょうが…) そこで(あまりうれしくない部分もありますが)、pa_ounitというライブラリを紹介しておきます。 https://github.com/till-varoquaux/pa_ounit (JS Core を使っている人はすでにJS Coreに付属しているpa_ounitが入っていると思います。) 「ちょっと気軽な」と書きましたがpa_ounit自体の中身はP4というドキュメント整備され
釣りなう(ぉ git nowでのコミットをディレクトリの変更を wait_on コマンドで検知して、保存時に自動的にやってもらおうというだけだったりする。 ビルド成功時のみ? テストが成功したら? なにそれおいしいの? トピックブランチに入ったら、管理するファイルを生成して以下のスクリプトに管理するファイル名を渡して実行しておけば、ファイル保存時に勝手にgit nowしてくれるという感じ。 #!/bin/bash git_now_loop () { git add -u git now sleep 1 } echo 'Managed files is' if [ $# -eq 0 ]; then echo `git ls-files` while : do wait_on `find . -type d ! -path '*/.git' -and ! -path '*/.git/*' -p
バージョン管理システムではよく行われるブランチを切るということ。 Gitでは分散バージョン管理であることを生かして、ローカルとリモート(中央リポジトリ)で違うブランチの状態を作ることが可能です。 つまりローカルで好きにブランチを切っておくことも可能だということです。 よって、非常に気軽にブランチを切ることができ、よく使います。 そして、もうひとつ。 バージョンのリリースの際などにコミットに「タグ」を打つことができます。 これをそのコミットを指すポインタの役割として使うことができます。 git checkout (ブランチをチェックアウトする) git branch (ブランチを操作する) git tag (タグを打つ) git checkout (ブランチをチェックアウトする) ブランチの切り替え(チェックアウト)を行うのが、 git checkout <ブランチ名>です。 ブランチの切り
Gitでバージョン管理をしていく際に、どうしても間違ったコミットやバグを含む内容の修正、ブランチの統合などを行う必要があります。 そういうときに使えるコマンドを今回は書いていきます。 ブランチのマージなどはブランチのまとめの方に書くべきかもしれませんが、リベースとの対比のためにこちらに書きました。 git reset (HEADの位置を変更する) git rebase (歴史の変更をする) git stash (一時的にインデックスを保存する) git cherry-pick (コミットを付け替える) git merge (ブランチをマージする) git reset (HEADの位置を変更する) HEADの位置を変更する(+ インデックス、ワーキングツリーの位置も変更する)コマンド。 単なる修正以外にも使っている人も多くいるらしい。 --soft HEADだけ位置を変更することができます。
Clojureでテストを書く、というのはclojure.testというものを用いることで簡単に達成できます。 今回はTDDを進めていく体で、テストの書き方を紹介していこうと思います。 お題は簡単に行うためにFizzBuzz*1です。FizzBuzzについてはWeb上に多く紹介があると思いますので割愛させていただきます。 これからコードを書いていきますが、コードはdiffのように追加した行は"+"、削除された行は"-"をつけることにします。 TDD最初の一歩とisマクロ TDDの最初は、「まずはテストから」ですよね。 +(ns fizzbuzz + (:use clojure.test)) + +(is (= 1 (say 1))) ここでは"say"と言う関数が、引数に1を受け取ると1が期待されるということを書いています。 これを実行すると java.lang.Exception: Una
TDDBCにスタッフとして参加したので、つれづれにメモ書き。 TDDBCで発表があったことの内容よりも、参加した中で考えたりしたことをちょっと書きだしておきたいと思います。 Keep グリーンの安心さと同時に細かいテスト実行を伝えられたのは大きかった。 最後にGitでローカルコミットを使えば、Undoを使うよりはるかに正確に楽にロールバックができることを伝えることができた。(git-now言い忘れた…) Problem ペアプロ時のTODOリストの活用はすすめたかった… パラメタライズドテストはxUnit系だとちょっとためらわれることもある気がする。単純な使いにくさであったり、テストコードの可読性の低下を招くことがある。(個人的にそう感じる) テストコードのリファクタリングも重要。 OUnitの機能が足りない。パラメタ表示させるのにMapとか使ってたらテストコードが埋もれる… USキーボー
実用期を迎えた関数プログラミング 最新動向と今後の展望 - http://atnd.org/events/27376 「実用期を迎えた関数プログラミング」参加してきました。 福岡では関数プログラミングの勉強会は少ないので、福岡で関数プログラミングのお話が聞けるというのは非常に貴重な機会でした。 今回は関数プログラミングの現状や基礎的な関数プログラミングについてのお話がメインでした。 「関数プログラミングのエッセンスと考え方」 ITプランニングの小笠原さんのお話です。 関数プログラミングの企業での応用例や、関数プログラミングのメリット、またそのエッセンスとして高階関数、コンビネータ、代数的データ型の話、そして最後に形式手法のお話がありました。 ITプランニングさんの形式手法の応用例として、D-BusとJSONの変換の部分をCoqで証明をしたということでした。この際には1週間という区切りを用い
今回はOCamlの現在のlatest versionである3.12.1には実装されていない、GADTについて試してみました。 とりあえず、現状でOCamlのGADTを試すにはOCamlのsvnリポジトリからgadtsをとってきてビルドとインストールを行う必要があります。 ただし、これを行うと、今まで入れていた標準でないライブラリのうち、cmiファイルが関係するライブラリはほぼ全滅します(多分)。つまり自力で入れ直しです。それにバージョン名が変更されたりする関係でoasisパッケージでOCamlのバージョン指定がある場合、そのままでは対応していないバージョンとして扱われるなどの問題があります。現状、そのまま普段の開発で使うにはかなり自力での解決が必要になりそうです。 それでは以上のことに注意しながら、GADT対応バージョンを入れてみます。 $ svn co http://caml.inria
boost::optionalの説明でも書かれていますが、一応メモ。 boost::triboolは3値論理と言われるものを表現するための型です。 一般の論理値、true, falseに加えて、indeterminate(不定)というものが加わっています。 これはboost::optionalに非常によく似ている気がします。 もちろん、これら二つの間には目的の大きな差異があります。 しかしながらこれらの違いとして、その他にも 1. 初期化の違い 2. 呼び出しの違い 3. 暗黙の変換の有無 が存在しています。(もちろん、論理演算を行う場合も結果が異なりますがそれは割愛します。) 初期化の違い 初期化の違いとしてはoptionalは初期化値を与えなければ、未初期化であるためにbool値を表していません。 しかし、triboolはfalseとなっています。 https://ideone.com
「私の使うGitコマンドまとめ」の記事を、逆引きとして使えるようにしてみました。 私がよく行っていることを「私の使うGitコマンドまとめ」の記事では書いていないオプションの組み合わせなども書きました。 目次 HEAD、インデックス、ワーキングツリーを理解する HEADからの相対的にコミットを指定する リポジトリを作成する 管理するファイル(インデックス)を操作する コミットを行う 現在の状態を見る 差分を見る コミットの詳細を見る コミットログを見る HEADの遷移を見る ブランチの操作をする タグを操作する ブランチの統合を行う 修正・手戻りを行う リポジトリの最適化する リポジトリの検証をする HEAD、インデックス、ワーキングツリーを理解する HEAD、インデックス、ワーキングツリーについて 簡易説明 HEADからの相対的にコミットを指定する HEADから相対的にコミットを指定する
というタイトルの通りのことを目指して、現在OCamlとOcsigenというWebアプリケーションフレームワークでWebアプリケーションを作ってみようと思ってます。 ちなみにこのOCamlとOcsigenというのはかなり癖のある環境で、私は今のところDebian上でしかOcsigenまで含めた環境構築ができてません。 WindowsはOCamlの環境として、必須となるようなライブラリ群もインストールにかなり手間取るのでやめた方がいいです。(正直、挫折必至) Macでもhomebrewによるインストールでかなり問題なさそうでしたが、ネイティブ用のコンパイル時にいくつかのライブラリでこけました。macportsは試していないのと、普通にインストールした場合を知らないのですが、homebrewでのインストールはいくつかのライブラリを使う場合(今回のOcsigenを含めて)、難しいです。。。 追記:
明日は大阪で楽しくXPを体験してこようと思ってます、なおきりんです。(XP一日体験ワークショップ! - http://kokucheese.com/event/index/30196/) 今回、継続的インテグレーションが参加するイベントの一つにあげられているので、先取りで独り継続的インテグレーション環境を作ることにしました。 ちなみに今回使っている環境は Mac OSX Lion (Mac book pro) JDK6(Mac上でのJDK7は挙動がまだ怪しいのでJDK6が安定のようです。2012/03/30現在) Groovy 1.8.6 Jenkins 1.454 Gradle 1.0-milestone-9 JUnit 4.10 spock-core-0.5 Git 1.7.7.5 となっています。蛇足ですがIDEはIntelliJ IDEAです!(ココ!重要!) Gradleでビルド
独りAdvent Calendarへの挑戦の一発目として、私がよく使うGitのコマンドをまとめていくことにします。 あまり使いこんではいないので役に立つかわかりませんが書いていきます。 git init (リポジトリの作成) git add (管理するファイルの指定) git rm (ファイルの削除) git mv (ファイルの移動・リネーム) git commit (コミット) git init (リポジトリの作成) cd path/to/repo git initで path/to/repo ディレクトリにGitのリポジトリの作成を行います。 リポジトリの作成の際に行われることはディレクトリ下に ls -a . .. .gitのように.gitディレクトリを作成することです。 この.gitディレクトリにGitの管理ファイルが格納されます。 つまり通常、このディレクトリ下を触ることはありま
なんとなく最近少し理論的な方面もやってみようかなと思い立って、今回はラムダ計算の基礎を勉強してみることにしました。 関数型言語の基盤らしいです。たしかにちょっと雰囲気はあります。 参考にしたページとしては Wikipedia ラムダ計算 - http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97 Wikipedia 型付きラムダ計算 - http://ja.wikipedia.org/wiki/%E5%9E%8B%E4%BB%98%E3%81%8D%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97 カリー・ハワード同型対応入門 - http://ocw.kyoto-u.ac.jp/ocw-archives-jp/002-006/pdf/curryhoward
TDD Advent Calendarに参加していないのに書くのも微妙なのですが、今回はTDDについてです。 TDD Advent Calendarの記事はかなりハイスペックな内容になっています。今回の私の記事はそれらには到底及ばないと思いますが、私の考えるTDDを書いて行こうと思います。 そもそもTDDとは 『TDDとはアジャイル方法論のエクストリーム・プログラミング(XP)のプラクティスの1つです。』 と言う話を聞きますがXPについてWebで調べてみると、「テスト駆動開発(TDD)」と書かれている場合と、「テストファースト」としか書かれていない場合の2種類の場合が存在します。 おそらく元々、「(Unit) Test First」と「Refactor」という2つのプラクティスがXPには存在していて、それがTDDというXP互換なプラクティスになって言ったのではないかと思います。 さらにTD
独りAdvent Calendar 第2弾として、Clojureについて書いていこうと思います。 Clojureは私自身最近始めたばかりの言語で、1ヶ月ほど合間を見ながら少しずつやってきた言語です。 そのため、あまりよいコードになっていなかったり、Clojureっぽくない書き方になっている部分も多々あると思います。 そのあたりはご了承ください。 そして、今回はClojureを使う上で私が素晴らしいと思ったClojure用のビルドツール、leiningenについて書いていきます。 それなりにleiningenのGithubにも詳しく分かりやすく説明されていました。 そのため詳細な使い方ではなくさっくりと、初歩的な簡単な使い方を紹介したいと思います。 まずはインストール インストールはとても簡単で、 まずhttps://raw.github.com/technomancy/leiningen/
次のページ
このページを最初にブックマークしてみませんか?
『What is it, naokirin?』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く