サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
blog.guildworks.jp
こんにちは、ギルドワークスの上野です。 ギルドワークスでは、開発したアプリケーションを Elastic Beanstalk を利用してデプロイ、運用しています。 EB CLI を入れることで、コマンドラインからデプロイすることもできますが、 自動化したいってなりますよね。 そこで自動化のやり方を調べたので、ブログにも書いておきます。 ちなみに自分のローカル環境に構築する際は、以下のコマンドで簡単にインストールできます。(python や pip がインストールされている前提) pip install awsebcli ですが、僕の環境ではどうもアップデートが上手くできなくて、いろいろいじってたらぶっ壊れて動かなくなったりしましたw brew で入れたら今のところ安定しています。 brew install awsebcli 1. circle.yml の設定 machine: python:
水谷です。 前回の記事でTensorFlowをアプリから呼び出して画像に何が写っているか認識するアプリを紹介しました。 その後、Google Could Vision APIの発表があり、より画像認識を使いやすいかたちで提供されることになりました。 発表ブログ Could Vision APIが何なのかやそのすごさはこちらの動画を参照してください。 先行プレビューの登録ができたので、ここではRailsアプリに組み込んで使ってみたいと思います。 画像認識 前回の記事と同じように、写真にあるものを認識してみましょう。 まず、APIには以下の形式で送信します。 { "requests": [ { "image": { "content": "jisYIujijJIUJI...." }, "features": [ { "type": "LABEL_DETECTION", "maxResults"
どうも、ギルドワークス 前川です。 さて、みなさーん、継続的インテグレーション（以下CI）してますかー！ さて、以前お伝えしたように、ギルドワークスでは、iOSの開発においても積極的なCIを行っています。 これは、特にリモート開発が多い環境では、正しいものを正しくつくる ために常に安定したベースラインで確認できる環境を作ることが、非常に重要だからです。 とはいえ、なかなかiOSの自動ビルドには越えなければ行けないハードルが多かったりします。 今回は、ある一つのiOSプロジェクトを作成してから、誰でも実機上で確認できるようになるまで（技術ベースで言うと、DeployGateを用いてAdhoc配信するまで）を、ざっと紹介したいと思います。 1. iOSアプリケーションを作成し、iOSアプリケーションをGithubにPushする まずは、大前提ですね。作成しているアプリケーションを、Github
水谷です。 先週、Googleが機械学習システム「TensorFlow」をオープンソースで公開しました。 曖昧な言葉や口語を的確に理解して検索結果をだすRankBrain、最近Inboxアプリに搭載された自動応答機能や、スマートフォンのカメラで看板の文字などを写して、その文字を翻訳してくれるGoogle翻訳アプリも、このTensorFlowをベースに開発されているようです。 詳しくはこちらなどを参照してください。 http://googledevjp.blogspot.jp/2015/11/tensorflow-google.html http://www.publickey1.jp/blog/15/googletensorflow.html http://www.itmedia.co.jp/news/articles/1511/10/news055.html ここでは、手っ取り早くアプリ
ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。 Robot Frameworkの紹介 Robot Frameworkは受け入れテスト、受け入れテスト駆動開発のための、python製の自動テストフレームワークです。 海外では利用されているようですが、日本ではなじみの薄いツールのようなので紹介したいと思います。 特徴は、キーワード駆動です。 「キーワード」と「キーワードの実際の動作」を定義し、テストケースでそのキーワードを組み合わせてテストを実行させます。 また、予めキーワードが実装されたライブラリを使用することができます。 例えば、Selenium2 Web Driverのラッパーである、Selenium2Libraryを使用することでRobot FrameworkでSelenium2 Web Driverを使用できま
ギルドワークスの佐々木です。 皆さんは、自分と相手のコミュニケーションがどのくらいコンテクスト（文脈・状況・背景）に依存してるか、意識していますか？ 今回はコンテクストというものについて考えたことを書きます。 ギルドワークス用語集 ギルドワークス内部で「ギルドワークス用語集」というドキュメントを作っています。 最初は私が出張の新幹線の帰りについカッとなって作成したものですが、その後メンバーによって手が加えられています。 （用語集は DocBase を利用して作成しています。） 用語集は国語辞典ではないので、一般的な意味は記載していません。 その組織、そのプロジェクトにおいて通じる言葉を記載したもの、と考えます。 一般的に「ピリッとする」、「御社」と言えば、それは辛味を表す言葉であり、お付き合いのある会社のことを指します。 ギルドワークス内部で使う時は、それぞれ「考えたことやデザインがいい感
こんにちは、ギルドワークスの中村 洋です。 先日、全員鎌倉に集まり「ワイガヤミーティング」をやりました。 「ワイガヤ」とは？ 立場の相違にかかわらず同じ組織に属する者たちが気軽に「ワイワイガヤガヤ」と話し合うこと。本田技研工業株式会社が提唱した言葉で、仕事・プライベートのどちらでもない職場での多人数による会話のことを指す。同社に限らず日本組織の特徴的なものともされており、仕事の仲間同士で突然発生し、周りの人たちを巻き込み進行する。テーマは会社の人間関係・仕事への不満などから、仕事とまったく関係ない話まで雑多。単なる時間の浪費か、仕事に発展的に役立つものかとの点で見解が分かれている。 コトバンク> 知恵蔵mini なぜやったのか？ ギルドワークスは普段はリモートワークですが、2、3ヶ月に一度は合宿をやっています。その上でさらに何をやるのか？と思う方もいるかもしれませんが、このワイガヤミーティ
こんにちは、上野です。 週末開発合宿を行ってきました。 その中で React Native によるアプリ開発にチャレンジしてみました。 一部では既にReactは大変という声もあったりしますが、ネイティブアプリも作成できるツールはあまりないので結構期待しています。 (最近 Androidアプリ も作れるようになりました) そんなわけで今回は React Native の環境構築について書いてみます。 事前準備 Macでのインストールを前提としています。 Xcode App Storeから最新版をインストールしましょう。 Xcode をインストール後 Command Line Tools も入れてください(最新だと自動で入るようです) Homebrew まだインストールしていない方は以下のコマンドを実行してください。 ruby -e "$(curl -fsSL https://raw.gith
ギルドワークスの佐々木です。 私はエンジニアですが、バックグラウンドとして人間中心設計（Human Centered Design：HCD）を学んできました。このエントリーでは、このHCDを否定するわけではなく、もう一歩進めて、User/HumanをCenterにするのではなく、CoreにしてDriveするのがよいのではないか、ということを書いてみたいと思います。 なぜ中心（Center）という言葉が使われたか 「ユーザー中心」、「人間中心」という考え方は、それぞれアメリカ、ヨーロッパが提唱した言葉でした。 これらの言葉が生まれた背景として、工業デザインとして大量生産が行われた際に、「製品中心」になってしまったことがあると考えられます。 元々、使い手と作り手は、一対一の関係でした。作り手は自然と使い手に合わせた製品を作っていたと考えられます。それが、産業革命以後、大量生産をすることで、使い
ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。 今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。（あまり本質的な話題でなくてすみません。。。） エンティティの識別子、どう実装していますか？ 私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。 ドメイン駆動設計本の例はどうでしょう・・・。 ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。 実践ドメイン駆動
井上です。 普段 Java でシステム開発を行っているのですが、ビルドツールとして最近は Gradleを使っています。 Gradle は 日本語のドキュメント や 「Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築」 といった日本語の情報が豊富で、Java界隈におけるビルドツールのデファクトスタンダードとなりつつあります。 Gradle におけるライブラリのバージョンの指定方法 Gradle では、プロジェクトで使用するライブラリを指定することで、そのライブラリ及びライブラリが依存しているライブラリ群を自動的にダウンロードする機構が備わっています。 以下、Java を使ったプロジェクトで JUnit を使用する際のGradle のビルドスクリプト (build.gradle) の例です。 apply plugin: 'java' sourceCompatibility = 1
どうも、ギルドワークス 前川です。 以前ご紹介した通り、ギルドワークスではドメイン駆動設計（DDD）の勉強会を社内で行っています。 その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。 「それ、ソースコードに書いてないじゃん」 それは、DDDを前提においたコードレビューで飛び出した指摘でした。 コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。 こういった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。 一方このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。 それを話した時に、弊社増田の口から飛び出たのが、、、 「んで、それはソースコードの何処
どうも、ギルドワークス 前川です。京都からリモート作業を行っていますが、この二週間は、祇園祭でとんでもない人出となっております。 リモートでの開発に必要なもの ギルドワークスでは、Webサービスだけでなく、iOSやAndroidの開発もリモートで行ってきています。その中で、最近一つのパターンとなっているのが「可能な限り初期に継続的ビルド（CI）を導入する」ことです。 もちろんCIは手段でしかありません。その目的は、「全員が同じものを見て確認する」ためです。対象がWebサービスならば、例えばHerokuにデプロイされたものを正として扱ってやれば、事は済みます。 しかしiOS開発では、そうはいきません。全員が「同じもの」を見ることが非常に重要ですが、それにはCIされた成果物を共通の場所においておき、それを参照する、これしかありません。 ここは結構厳格にやらなければいけない、と私は思ってます。例
上野です。 最近herokuを本番で利用する案件に携わっていまして、改めてTips的なものをまとめてみます。 Tips 1. 画面からConfig設定を変更する 知っている方は多いと思いますが、Configは画面から設定できるようになっています。 (昔はコマンドで行っていましたが。。。) heroku の Settings から Reveal Config Vars を押すと内容の表示ができたり、Editで編集もできるようになります。 知らない人はぜひお試しください。 Tips 2. GitHubから自動連携でデプロイする こちらも既にかなり前からできるようになっていますが、masterへのマージ等をフックして heroku に自動デプロイができるようになっています。 自動デプロイだけではなく画面からブランチを選んで手動で行うこともできます。 他にも Dropbox 連携なんかもできるよう
井上です。 以前、本ブログでドメイン駆動設計(Domain-Driven Design 以下 DDD)のリファレンス本について紹介致しました。 おかげさまで非常に多くの方にご覧頂いたようで、DDDの注目度を改めて感じました。 また、「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本) に続く２冊目ドメイン駆動設計本として、「実践ドメイン駆動設計」(以下 DDD実践本) も出版され、日本におけるDDDへの注目度がさらに増しているように思います。 私自身、普段からDDDを用いた開発を行っているので、日本語で多くのDDD情報が入手できることはとても嬉しい限りです。 そんな中、DDDを冠した「Patterns, Principles, and Practices of Domain-Driven Design」という新しい本 (以下 DDDパター
こんばんは、ギルドワークスの藤田です。 皆さんの職場は、業務時間中にイヤホンをするのがOKな職場ですか？ ギルドワークスではイヤホンOK、というか、そもそも仕事中にこうしなければならないという縛りが何ひとつなく、靴下を脱ぎ始めたり壁に足をたてかけたりして仕事をする代表がいたり、正座しながらチョコパンを食べてPCに向かう現場コーチがいたり、そんなフリーダムな雰囲気ですが、私は集中したいときは爆音で音楽を聴くことが多いです。 そのせいもあってか、「このお客様のテーマソングは○○だな！」とか、「このサービスのテーマは■■だ！」とか、音楽や人をイメージすることが多いです。 先日も、とあるお客様のトーン＆マナー設定をおこない、UIイメージを作成したのですが、サービスのコンセプトを知った時から、「これはB’zだ！ B’zの”Times Flies”だ！」と、そのお客様の仕事の時は常にB’zを聞きながら
ギルドワークスさんとパートナーとして一緒にお仕事させていただいています 木目沢(@pilgrim_reds)と申します。 このような場で記事を書かせていただけることになりまして大変緊張しております。 今回は、Kent Beckが書いた「実装パターン」という本を紹介したいと思います。 出版社の都合で絶版になってしまっているのですが、素晴らしい本ですので、もし手に取る機会がありましたらぜひ読んでみてください。 この本のテーマは、「よいコードを書く方法」です。 190ページという薄い本ながら、「よいコードを書く」ためのパターンが100個近く掲載されています。 なにより素晴らしいのは、パターンを紹介するだけでなく、 そもそもよいコードとは何か？ なぜよいコードを書く必要があるのか？ パターンとは何か？ どのようにパターンを選択し、適用すればよいのか？ という本のテーマの「前提」となる部分がきちんと
ギルドワークス 前川です。 自信を持って言えるほどではありませんが、英語はちょっとは読み書きできます。そもそも英語の強さは、二種類あると思います。 一つは、語彙力。じつはこれ、僕はあんまりありません。なので結構英辞郎やロングマンの英英辞典を引っ張ってくることは多いです。 もう一つが、文法力。というか、英語のルールを知っておくこと、ですね。こっちのほうが僕は少し得意です。 文法と聞くと、あんまりいい顔する人はいないでしょうが、本来英文法ってのは英語の考え方を知るためのツールなんです。なので、幾つか知っておくだけで格段に英語の見方が変わりますよ。 そんなわけで、恐らく最も簡単な英単語の一つ、にして、多くの人が重要性を意識せず使っている”the”についてお話します。 定冠詞 “the” “the”は文法上の分類で「定冠詞」と呼ばれます。「定冠詞」があれば「不定冠詞」はあるのか？というと、あります
ギルドワークスの佐々木です。 私は宮城で働くリモートワーカーで、以前の記事(ギルドワークスのリモートワークを支える技術)でご紹介した通り、様々なツールを使ってリモートワークを実現しています。 その中で最も利用頻度が高いツールは slack です。 今回はこの slack についてお話したいと思います。 リモートワークをしていると感じる瞬間 業務時間中、slackの投稿がふと途絶える瞬間があります。 こんな時、少し不安になってしまうことがあります。 小さな不安ですが、リモートワークをしているとなおさらかもしれません。 もちろん、これはみんなが仕事をしてないわけではなく、単に客先打ち合わせや作業中で投稿がなくなっただけです。 逆に、slackの投稿が急に増えることがあります。 よくあるのは、連携している pivotal tracker や github からの更新通知が大量に届くことです。 あ
ギルドワークスの市谷です。 先日の金曜日土曜日をかけてギルドワークスとしてビジョン合宿へ行ってきました。仙台、大阪、京都、東京の各メンバーが一同に会するのは3ヶ月ぶりのことです。普段時間をかけて話せていないことに、ゆっくりと費やす。今回の合宿は互いが目標として置いてることについて共有とフィードバックをする目的で行いました。 ギルドワークスでは個人の目標を3つの軸で各人が設定しています。 ① 事業目標達成のために設定する個人目標 ② 個人の成長目標(1年後に目指している状態) ③ チーム(他のメンバー)に何でもって貢献するつもりか ①は事業として置いている目標を、どのような個人の目標に置き直すかというものになります。各メンバーの目標が事業の目標達成に繋がるように設定をします。 ②は各メンバーが1年を通じてどのような状態になることをめざすのか、という個人のビジョンになります。どのような仕事や活
はじめまして、前川(a.k.a @Posaune)といいます。4月から、ギルドワークスの一員となりました。 京都を拠点として、サービス提案からコーディング、CIなどのプロセス改善まで、サービスのライフサイクル全体に関わるALMエンジニア（≒何でも屋）として、これから頑張っていきますので、よろしくおねがいします。 最初の記事として、自己紹介とエンジニアとしての知識獲得のモデルケース紹介を兼ねて、私がどのような視野の広げ方をしてきたのかを書いてみます。 1. 新しく知る 私のスタート地点はプログラミングです。ただ、先輩に恵まれたおかげで、割と早いうちから「勉強会」というものに参加していました。 最初のうちは、見ること聞くことへの好奇心で、色々な勉強会に行きまくっていましたが、そのなかでも心を引かれたのが、「アジャイル開発」をテーマにした勉強会でした。 開発に関わり始めたばかりの若手でしたので、
次のページ
このページを最初にブックマークしてみませんか？
『GuildWorks Blog | あなたの課題を技術者のつながりで解決する「ギルドワークス」』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
