社内に新人が増えてきたので、弊社のWeb開発でのGitのゆるーい利用方針をまとめます。 本当はネガティブなことばかり書かずに、「覚えて欲しいコマンド、使ってほしくないコマンド」というタイトルにしたかったのですが、予想以上に長くなりそうなので分けます。 (追記：第二弾できました) →　[社内新人向け]Gitで絶対にオススメなプラグインや設定3つ 社内環境 Web系開発がほぼ100％ ブランチワークはGitflowをベースにしたプルリク駆動開発 少人数チームなので、エンジニアは全員LinuxのCUI操作をできて欲しい（vagrantや開発サーバ上の操作など） GitのGUIクライアントは、SourceTreeとGithub公式を試しましたが、初学者が使うと却って危ない挙動をしてしまうケースがあったので、全員CUI操作をしてもらうことにしました CIツールはまだ導入できず。各サーバーへのデプロイ

システムエンジニア Advent Calendar 2016 の 15 日目です。システムエンジニアなら避けては通れない設計について考えたことを書いてみようと思います。 設計ってむずかしい システム開発の様々な局面で「設計ってむずかしいなあ」と思うことがあります。細かいところはシステムの規模や自分のポジションによって変わりますが、だいたい以下に挙げたようなことで困ることが多いです。 設計 なにを、どこまで、どんなフォーマットで書くといいんだろう？ 各ドキュメントはどうやって関連付けるといいんだろう？ 基本設計書と詳細設計書はなにが違う？ 開発 なんでこういう設計になっているんだろう？ 設計されていない組み合わせのデータはどう処理すればいいんだろう？ 試験 試験データのパターンや量はどれくらい用意すればいいんだろう？ 運用 設計と実装が乖離していてなにが正しいのか分からない... 仕様変更や

この記事では、GitBucketの検索機能を強化するプラグインgitbucket-fess-pluginについて紹介します。 このプラグインは、GitBucketと、全文検索サーバー Fessを連携させることによって、 複数のリポジトリ間を横断する検索を 高速に 行えるようにします。 以降、今回紹介するプラグインのことをFessプラグインと呼びます。 これはFessプラグインを使用した際のGitBucketのスクリーンショットです。 "code"という文字列を含むソースコードを、複数のリポジトリを対象に検索できていることが分かると思います。 FessプラグインはGitHub上で公開しています。 GitHub - codelibs/gitbucket-fess-plugin (追記 2017/3/20: 記事執筆時はβ版でしたが、このたびバージョン1.0.0をリリースしました! ) この記事

みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。 さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の

久しぶりにApache Jakarta HttpClientを利用してみたところ最新の4.3であまりにもインターフェースが変更されていて非推奨の警告ばかりでてきました。 警告なので当面は動作するのですが今後のことを考えて正しい使い方を調べてサンプルコードを作成してみました。 2013年11月現在、英語も含めてあまりサンプルソースコードが見つからないので参考にしたのは本家のJavaDocとソースコードを追って確認しました。 これまで使い慣れていた人にとってdeprecatedが多くなってしまうほどの大幅な変更です。 本家JavaDoc https://hc.apache.org/httpcomponents-client-4.3.x/httpclient/apidocs/ 大きな変更点として、実装面ではスレッド処理に強い実装になっていること、プログラミング記述上の変更点としては設定系がそれぞ

はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ

ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ

初めに これは G* Advent Calendar 2016 の 14 日目の記事です。 最近は AST 変換にハマっています。ただ、AST 変換はドキュメントが少ないのが難点です。ネットで検索しても、メソッド呼び出しを 1 行追加するなどの簡単なものしか見つからない上に、Groovydoc を見てもメソッドの説明があまりないので、複雑なものを作ろうとすると非常に苦労します。ということで、AST 変換を作ろうとしている人の助けに少しでもなるように、自分がやったことを公開していこうと思います。 AST 変換について Groovy には AST 変換という機能があります。簡単に言うと、Groovy コードがバイトコードにコンパイルされる中間の段階で、プログラムの内容を書き換えてしまえる機能です。 これによって、いわゆるボイラープレートコードを削減したり、Groovy の構文をある意味で拡張し

ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか？最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても

今はやりのElectronを使ってWindows用アプリをパッケージングしようとしたところ、環境周りの様々な問題にぶつかって大変でした…。 備忘録と情報共有をかねて、恥をしのんで書き記します。 確認環境 Mac OSX Yosemite(10.10.5) node v4.2.3 electron v0.35.4 パッケージング用コマンドを実行するとエラーが出る Electronのパッケージングにはelectron-packagerを使用します。 Windows向けのパッケージングを行う時は、下記のようなコマンドを実行します。 $ electron-packager <ソースディレクトリ> <アプリ名> --platform=win32 --arch=x64 --version=0.35.4 --icon=<アイコンファイルのパス> --overwrite

本記事が切っ掛けとなってお声がけを頂き、本記事の増補リファイン版となる記事をSoftwareDesign 2018年1月号のシェルスクリプト特集第2章として執筆しました。リファイン版には、この記事で触れていない文法面での分かりにくさについての解説が含まれています。その文法面での分かりにくさの解説の一部に相当する記事もありますので、ぜひそちらも併せてご覧下さい。 Shell Script Advent Calendarをご覧の皆様、図々しくも5日目に続く2度目のエントリーのPiroです。 前回は自作のBashスクリプト製Twitterクライアントをネタに実装を解説しましたが、今日は他の言語で多少のプログラミング経験はあるんだけど、どうにもシェルスクリプトは苦手だ……という人のための、シェルスクリプトによるプログラミングの勘所を解説してみようと思います。多分、プログラミング入門レベルの人や上級

この記事は freee Engineers Advent Calendarの6日目です。 こんにちは。freee株式会社でアプリエンジニアをしている @kompiroです。主に会計freeeの開発に携わっています。 僕には「よりよい機能を、より早くユーザーに届けたい」という信念があります。今日はよりよい機能を、より早くユーザーに届けるためのGit/GitHubを活用する10の方法と題してGitやGitHubの便利な使い方や日々のTipsをお届けします。1 PRのレビュー完了までの時間を最速にするための工夫 freeeではGitHub上でレビューをしながら開発を進めています。レビューをするのもされるのも、うまく進めないと結構時間がかかります。もちろんコードをより良くする作業に時間を割いているのであれば時間がかかるのも致し方ないです。しかし、進め方による問題でも数日〜数週間デプロイが延期されれ

Gitリポジトリからソースをクローンする。 $ git clone <リモートのクローン先> [optional ローカルのフォルダ名] リモート操作 リモートブランチも含めたブランチ一覧を表示する。 $ git branch -a 例) $ git branch -a feature2535 feature2558 * master remotes/origin/1.2.1 remotes/origin/HEAD -> origin/master remotes/origin/testbra リモートからブランチを取得する。 $ git fetch origin <ブランチ名> リモートからブランチをチェックアウトする。 $ git checkout -b <作成ブランチ名> <リモートブランチ名> 例) git checkout -b testbra origin/testbra リモ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 画像: N高等学校課外授業(N予備校)での生放送授業のブラウザ上での見た目、コメントが書ける 目次 はじめに 教えることになったきっかけ Web企業にエンジニアとして就職できるようになる、というミッション 既存のWeb教材に感じた問題意識 「各自進められるゲームブック形式の教材」と「徹底的にフォローする生放送授業」 コンセプトをもとに構成されたコースと内容 ゼロからプログラミングができるようになった人が生まれた日 永劫、プログラミングは一部の天才たちのためのものか？ プログラミング学習のモチベーションの課題と対応 まじめなオタクたちが社

TOPIC Redmineを3年間使い続けてお世話になったプラグインたち（全部、無償版） ＜書かないこと＞ Redmineの操作説明（インストール、操作方法など） プラグインの操作説明（インストール、操作方法など） ＜補足＞ 利用当時（2016年夏頃まで）の状況によるものとなりますので、最新の情報については要再確認となります。（当時はなかったものが今はあるかもしれないし、逆も然り） ※ 私が使っていたRedmineは、【Bitnami Redmine 3.1.1-1】となります。 （これまでのRedmine：2.3 → 2.6 → 3.1） ※以下、1つずつピックアップしていきます。 clipboard_image_paste（Attach image from clipboard） https://github.com/peclik/clipboard_image_paste 使用頻度：

コード改善 meetup #2 http://kaizen.connpass.com/event/42118/ の発表資料。 自己紹介 名前: 正徳 巧 会社: 株式会社grooves 言語: Ruby github: sinsoku twitter: @sinsoku_listy コードを改善する 3つの方法 コードを改善する3つの方法 1. コードを削る 2. コードを直す 3. 増殖を防ぐ コードを削る よくありそうな業務コード 条件分岐が多い 似たような処理が複数箇所にある コピペっぽいけど微妙に違う 既存の仕様が謎 ココロ、オレル 未使用メソッドを探す 未使用メソッドは基本的に 全削除 する。 全削除に対する不安 いつか使うかも... disabled? の対象性のため enabled? も... どこかで使っているかも... 全削除に対する不安 いつか使うかも... disab

はじめに 近年，機械学習の分野でディープラーニング(ディープニューラルネットワーク:DNN)に注目が集まっています．それに伴って様々なDNNライブラリが公開されていますが，それぞれどんな違いがあるのでしょうか（どれを使えば良いのだろう）．本稿ではDNNのネットワーク構造を，各ライブラリでどのように記述するのか比較してみたいと思います． 本稿で想定するのは，DNNについてはある程度知っているが，ライブラリについては知らないという方への説明です．各ライブラリのチュートリアルを読んで実際にコードを書いたことがある場合は，それ以上の内容はないです． 多数のライブラリが公開されていますが，本稿ではchainerとTensorFlowの2つを扱います．将来的には他のライブラリについても追加できればと思っていますが． 以下ではまず各ライブラリの簡単な基本情報だけまとめてみます．速度等の比較は Pytho

Dockerとは コンテナベースのアプリケーションを仮想化したもの。軽量なVMの様に見えるがこれまでの(VirtualBoxなど)VMでは実現が難しい、不可能であったユースケースを解決してくれる。 ホストOSとリソースを共有するのでリソースの管理がVMより効率的 基本的に状態を持たないのでポータビリティが非常に高く、特定の環境に依存することがない 軽量なのでVMと比較し複数のインスタンスを実行することができる DockerHubなどのレジストリを利用することで既存のイメージをダウンロードして実行することができる コンテナとVM VM VMはハイパーバイザを通してホストOSに対してのシステムコールを解釈させるなどの必要がある それぞれのVMには全て独立したOS・アプリケーション・ライブラリが必要 コンテナ ホストのカーネルは実行されるコンテナと共有される（コンテナは常にホストと同じカーネルを

業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)

Docker ? Packer ? 何が違うの？と個人的にわけがわからなくなっていたのでまとめてみた インフラ系技術の 3 つのレイヤー Orchestration アプリケーションのデプロイ Capistrano Configuration ミドルウェアレベルの設定 Chef, Puppet Bootstrapping OS のインストールにあたる領域 Docker, Vagrant, Packer 今回は、Configuration ツールと Bootstrapping ツールの違いをまとめる Bootstrapping Tool Docker 公式ページ Linux コンテナの内部でアプリケーションを動作させるためのツール Go 言語で記述されている 環境構築は Dockerfile と呼ばれるファイルでコード化できる コンテナ型仮想化を提供するツール イメージの作成から実行まで A