真面目に禁則処理を考えるとこんなにライトな実装ではツッコミどころ満載かとは思いますが、まぁ今のところ必要十分に機能しています。まとめgolang.tokyoに参加するのは今回で3回目ですが、画像処理は直近で向き合っていたテーマだったのでいつも以上に深い理解を得られました。「Goのことなんて全然好きじゃないんだからねっ!(好き)」というエンジニアを絶賛採用中です!ご興味ある方はぜひぜひ!、まずはカジュアル面談でお会いしましょう。07:30golang.tokyo#19の参加レポと、GoでOGP画像を作った話Tweetもっと読むコメントを書く2018-07-20業務未経験からエンジニアになって半年を振り返るこんにちは、ハウテレビジョンエンジニアのFです。ご存知の通りここ最近のプログラミング学習ブームを機に、プログラミングを勉強する非エンジニアの方スクール等に通いエンジニアに転職する方が増えてきているかと思います。私がハウテレビジョンにジョインしたのは2017年10月で、それまでエンジニアとしての業務は完全未経験でした。エンジニアとして採用されました。エンジニアになって半年ちょっとの間でやってきた業務、感じたことなどを書き綴ります。エンジニアとして採用されるまで大学時代は商学部で主にマーケティングを学ぶ、根っからの文系人間でした。これまで「プログラミング」とは無縁の生活を送っておりました。そんなあるとき、プログラミングに関する雑誌記事に出会いました。就業後、家に帰ってはPCを開き、時間をかけながらも一つのアプリを作り上げました。これをきっかけに「ものつくり」の楽しさに目覚め、独学でプログラミングを学びはじめました。「もっとやりたい」という気持ちがありました。Twitter上で見つけたTECH::EXPERTの相談会に足を運んでみました。その半年後には商社を退職し、TECH::EXPERTでの勉強漬けの毎日(1日10時間×週6日×3ヶ月間)が始まったのです。約3ヶ月のカリキュラムを終え就職活動をする中で、サービス志向を持つエンジニアを目指していきたいと考え「自社サービスを開発する企業」に興味を持ちました。して、面接を受ける中で自分に合うと感じたハウテレビジョンに入社しました。自分にとってはここからが本当のスタートです。様々な業務を行ってきました。具体的には下記のようなことを主に行いました。ビジネスサイドから上がってくる要望に基づく実装。小さな機能や少し大きな開発(長期インターンサービスのリリースなど)。上記のような業務の中で、実際に自分が関わりリリースされた機能を紹介します。長期インターンページgaishishukatsu.com入社して2ヶ月経った頃に関わった、はじめての大型開発でした。リリースされたときの達成感は大きかったです。こちらは現在でも、改善に向けたプロジェクトの開発に携わっています。企業配下(企業の年収/社風などを紹介する)ページgaishishukatsu.comここ最近だとこちらの開発に関わりました。見積もりから進め、ビジネスサイドと密に話をしながら開発していった案件でした。完全未経験だった頃から考えたらたった半年ほどで様々な開発に携われていることに驚きがあります。そのあたりは入社後もある程度キャッチアップしやすかったです。感じた部分ももちろんありました。卒業していれば「ネットワークの仕組み」みたいなところから学べるだろうがそうでもなく。スクールのカリキュラムに説明はあったが、さっと触れる程度。業務で実際に必要になった場面はないが、経験あるエンジニア達の会話についていくときに必要と感じた。SQLこちらもカリキュラムではほんの触りのみ程度だった。エンジニアになる前に思っていた以上に分析系タスクが多かった。「もっと勉強しておけば...」なんて部分は上げたらキリがないですが、特にこの2点はGapがあったなと感じました。上記の課題を克服する上で、まずは下記のような本を読み漁り、勉強を進めました。受験していた人もおりました。SQLに関してはじめてのSQLこの一冊をやれば基礎部分は十分身につくかと思います。なければ会社負担で購入もしてもらえる制度があります。TECH::EXPERTを否定するつもりではありません。)mエンジニアになってからの学習や意識についてエンジニアになれたとはいえ、もちろん学習が終わりではありません。技術力を高める、会社・チームに貢献するために何をすべきか自分なりによく考えました。ここではその後の勉強法や意識してきたことについて書いていきます。自社サービスの運用では、どうしても「サービスを一から開発する」という機会はなかなかないと思います。してもコードを書く時間が限られる場合もあります。(弊社の場合、基本的には書けますが。技術力を高めていくためには、エンジニアを目指していた頃同様に業務時間外でも開発・学習が必要になるかと思います。個人的に考えているのは、写経でもなんでもとにかく手を動かしてアウトプットすることが大事だということ。内容にはこだわり過ぎずに気楽にやっていくのが良いかと思ってます。ここで私が入社してからの間、週末などの時間を使ってやってきたことを書きます。定番ProgateドットインストールUdemy言うまでもない定番どころの学習サービスを使った勉強法です。ド初心者の言語などはこのあたりで学ぶのが効率的かなと思います。Udemyは環境構築〜ちょっとしたサービスを作り〜リリースまで学べるコースがあるので、開発の流れを掴むという点ではおすすめです。駆け出しエンジニアや非エンジニアだけどプログラミングをかじってみたい方などにおすすめです。定番ではないですが、その他やってきたことです。「既存サービスを真似て作ってみる」に関しては、「DB構造はどうなっているのか」「ここをこうしたほうが良いサービスになるな」と考えるだけでも勉強になります。これらプライベート開発での成果はもちろん業務の中でも役立っております。できるだけ多く自社のサービスに触ることで把握するようにしました。おかげでビジネスサイドからの相談をスムーズにこなせるようになりました。(まだまだ先輩エンジニアの方々には遠く及びませんが。「個性」「強み」のひとつとして考えました。私の場合、前職が営業職だったこともあり、「ビジネスサイドとのコミュニケーション」を特に意識しました。ビジネスサイドからよく開発相談や開発依頼をいただけるようになりました。技術力だけで勝負をすれば、経験豊富な先輩エンジニアには及びません。それでも自分なりに会社やチームに貢献できるところはあるはず。これからも個性を生かして貢献していけたらと考えています。終わりに偉そうに書いてきましたが、まだ業務経験も1年に満たない駆け出しのエンジニアです。これからも日々精進していきたいと考えています。積極採用中(実際にTECH::EXPERT経由で新たに1名採用決定!!)です。ご興味ある方はぜひ弊社に遊びにきてください。18:57業務未経験からエンジニアになって半年を振り返るTweetもっと読むコメントを書く2018-07-17Docker初心者がRails+MySQLの環境構築をDockerでやってみたはじめに先日リリースした弊社のリニューアルされたiOSアプリのサーバーサイドはDockerで環境構築されております。Dockerはとても便利で、設定されていば簡単なコマンドを叩くだけであっという間に開発環境が整ってしまいます。先日何気なく弊社のDocker周りの設定をふと見てみたら、何が書いてあるか全く理解できず(TдT)これはまずいと思いDockerの勉強をはじめることにしました。今回はDocker初心者が勉強がてらRails+MySQLの環境構築ができるか試してみました。今回構築するのは以下の環境です。ドキュメントDockerfile作成Dockerfileとは、Dockerコンテナの構成内容をまとめて記述しておくファイルです。ここに書かれた内容をもとに、Dockerイメージが構築されます。$APP_HOMEDokerfileで使用している命令について軽く説明します。FROM(必須)コンテナのベースとなるイメージを指定します。DockerHubで公開されているイメージや、自作のイメージも指定できます。ENV環境変数を設定します。RUNFROMで指定したイメージ上で、コマンドを実行します。パッケージのインストールなどに用います。WORKDIR作業するディレクトリを変更します。ADD指定したファイルやディレクトリをコンテナ内にコピーします。※上記以外にも命令はいくつかあるのでご興味があれば公式ドキュメントを参照ください。今回はversion:5.2.0を指定しています。5.2.0'Gemfile.lockを作成Gemfile.lockが必要なので、空のファイルを作成しておきます。複数のコンテナを一括管理するための構成管理ファイル。コマンドで記述したサービスが全て立ち上がります。今回はRubyとMySQLの2つのコンテナの設定をします。db上の記述について軽く解説します。ファイルのバージョンを指定できます。imageベースイメージを指定します。portsホスト側とコンテナ側の両方のポートを指定できます。(ホスト:コンテナ)コンテナポートのみを指定した場合は、ホスト側のポートはランダムで指定されます。volumesボリュームをマウントするときに指定します。env_file指定したファイルから環境変数を追加します。depends_onコンテナの作成順序と依存関係を決められます。※開始の順序を制御するだけで、コンテナ上のアプリケーションが利用可能になるまで待つという制御は行いません。※上記以外にも命令はいくつかあるのでご興味があればこちらについても公式ドキュメントを参照ください。.env.dev作成パスワードは別で管理したいため、.env.devを作成します。ここに任意のユーザーとパスワードを設定します。newコマンドを実行します。ここでdatabaseにMySQLを指定します。下のコマンドでRailsサーバーとMySQLサーバーを起動してくれます。最初はデータベースがまだ作られていないので、以下のコマンドでデータベースを作成します。アクセスなんとかRailsが動いていることが確認できました。まとめ今回はDockerを用いて、Rails+MySQLの環境構築を試してみました。Dockerに関しての知識があまりなくても、最低限ですがRails+Mysqlの環境構築はできました。個人的にはDockerの学習は、コンテナを立ち上げるまでは学習コスト低めだと思いますが、実際の運用にはもっと多くのノウハウが必要なので、総合して学習コストは高いのかなと感じました。その反面、他の作業者と同じ環境が簡単に用意できるのはとても魅力的だと感じました。Dockerを触ったことがない方はぜひ触ってみてはいかがでしょうか。ハウテレビジョンでは絶賛エンジニア採用中です!ここまで読んで頂きありがとうございます。19:06Docker初心者がRails+MySQLの環境構築をDockerでやってみたTweetもっと読むコメントを書く2018-07-13半年でエンジニア4人→12人に急増したチームで、iOSアプリ(ReactNative)とAPI(Golang)を作り直して無事リリースした話(前編)はじめにどうも。メンバーの採用で、それに加えてアプリリニューアル以外の開発案件のとりまとめなども並行してやってました。今回のリリースはiOSアプリのデザインを根本的に見直すことでもっともっと使いやすいアプリにすることが最大の目的でしたが、ReactNative、Go、Dockerを使うという、技術的に大きな挑戦も含んでいました。VirtualBOX+Vagrant+Chefを使っていました。(一部今も使ってます)今回の記事では、この大きな技術的転換点をどのように乗り切ったのか、チームビルディングの観点から振り返りたいと思います。超大作になりそうなので2〜3記事に分けて書きます。~スマホアプリからのアクセスが急増スマホアプリをリリースしたばかりの2015年頃はスマホよりPCからのアクセスが大勢を占めていた外資就活も、いつしかスマホからの利用が上回るようになり、特にアクティブ率の高いユーザーが多いスマホアプリ改善への要望も高まっていました。リニューアル前の外資就活アプリはログインしないとほとんどの機能が使えない仕様で、「すでに会員登録済みのユーザーにより便利に使ってもらうアプリ」という代物。デザイン的にも最新のAppleUIガイドラインに準拠していませんでした。これを、「とりあえずアプリをDL→めっちゃ便利→面倒だけど会員登録してみよう」という順番にUXを入れ替え、さらにデザインも直感的に使えてより便利なUIに作り変えようという声が高まり、iOSアプリのリニューアルが外資就活の最重要ミッションになりました。2017年8月の話です。ReactNativeだ!!!!しかし当時の開発チームにはWeb出身のエンジニアしかおらず、スマホアプリネイティブの改修となると腰が重たい状況が続いていました。小さな開発チームでは各社課題になっていることですね。当時は開発リソースが少なかったこともあり「ネイティブアプリだけど中身はWebViewの箱のようなアプリにしてしまおう!」という企みも検討されましたが、結局は「ユーザーにぬるぬるサクサク快適に使ってもらうアプリを作る上でネイティブでの開発が必須」という結論に至りました。言ってもWebとiOSとandroid全部修得してその後もメンテし続けるのはやはり現実的ではありません。そこで当時にわかに人気が高まっていたReactNativeの導入を検討するようになりました。この背景には、スマホアプリだけでなく何ならWeb側もバックとフロントのコードを完全に分離し、フロントはReactで固めたら最高だぜ!という企みがありました。もの使って本当に大丈夫か!?」という懸念はありましたが、メルカリさんがReactNativeの開発案件で求人を出し始めたのを見て背中を押され「よし、RNで行こう!」と決意が固まったのを覚えています。ちなみに僕はJS大好きっ子なので、この選択を心から歓迎していました。Goだ!!??外資就活のバックエンドは複数に分かれたWebアプリ(本体のWebアプリ、スマホ向けのAPI、社内向けの管理システムなど)がDBにつながっており、そのWebアプリ同士が一部無秩序に相互参照していたり、それぞれがほとんど同じコードを重複して持ってしまっていたり(コピペコード問題)、CakePHP2系のサポートが切れそうだったり、そもそもPHPを使っていたり、と、いくつもの課題を抱えていたため、かねてから技術的負債解消への糸口を探していました。最大の課題はDB設計の不味さ(外部キーが無い、良くないポリモーフィック、今は使われていないテーブルやカラム達、命名規則バラバラ...など)なのですが、前述のような状況では手の出しようがありません。スマホアプリを大幅に作り直すにあたりユーザー認証周りの仕様を大幅に変える必要があったのですが、既存のバックエンドのコードに新仕様でのコードを追加していくのは影響範囲が広すぎて設計が難しく、何よりお世辞にも楽しい作業とは言えませんでした。して既存APIを拡張するのではなく、新APIを構築して徐々に既存処理を統合していく方針が決まり、技術選定へ。Java、Go、Kotlin、PHP7など、いくつかの言語やフレームワークでAPIのサンプルを作成し、どれにするか検討しました。負債解消は先が長いプロジェクトで、しかも非エンジニアのメンバーからはその必要性が理解されづらいものです。そこで、今回の技術選定ではエンジニア目線での「楽しさ」を重視することにしました。楽しければそのプロジェクトは勝手に進むし、やりたい人も自ずと集まってくるものだと確信したからです。後で書きますが、素敵なエンジニアが勝手に集まってくることはありません。相応のアクションは必要です。)そんな中でGoを選んだのは以下のような理由からです。するか悩みましたが、botmanの鶴の一声でサクッと決まりました。ちなみに、こんな感じでサクッと決まった。Chef.また、開発環境および本番環境のインフラ構築にはDockerを使いました。「今どきコンテナ環境使わないのやばい」という世の中の見えない圧力を感じ、当たり前のようにDockerで環境を作り始めました。実際Chefと比べても、各コンテナごとに何をやっているのかシンプルに記述されているため、インフラが苦手な自分でも理解しやすいという印象でした。~こうしてプロジェクトが始動したのが2017年8月下旬。当時の開発チームにはエンジニアが4人しかおらず、ReactNativeやGo、iOSアプリ開発の経験がある人はいませんでした。Dockerはかろうじて開発環境で使ったことがありましたが、本番運用の経験はありません。ここまで聞くとあまりに無謀過ぎて「アホなの(^ν^)?」と自分でも思います。何はともあれエンジニアを採用しないと翌年5月のリリースに間に合わない!そんな逼迫感からまず募集をかけたのはiOSアプリのネイティブエンジニアです。前述の通り、リニューアル前のiOSアプリはSwiftで書かれているのですが、新アプリの開発に加え、既存のアプリのメンテや緊急度の高い機能追加もやる必要がありました。RNで開発するとは言え、Webとは違うアプリ開発の常識を心得ていて、一部のネイティブとのブリッジコードを書いてくれるネイティブエンジニアの存在は必要不可欠でした。このときジョインしてくれたNさんは、iOSアプリの開発案件が日本で出始めたばかりの頃(10年前くらい)からアプリ開発を専門でやっている超ベテランでした。10月から8ヶ月間ともに働くことが出来ましたが、他のメンバーからも「Nさんみたいなエンジニアになりたい」と憧れられるような偉大な存在でした。Nさんを紹介してくれたのはギークスさんという会社で、数人紹介してくれた中でNさんと出会い、約1ヶ月後から一緒に働き始めることになりました。業務委託という形式にも関わらず開発合宿にも参加してくれるなど柔軟に対応頂き、本当にありがたい限りでした。Webエンジニア2名ジョイン!!iOSアプリのリニューアルが最重要案件だとしても、明らかな不具合や会員数を伸ばすためにどうしても試したい施策、売上を達成するための新商品開発など、サービスを運営し続けている以上目先の開発タスクは山のように降って湧いてきます。本当に優先度の高いものだけに絞ったとしても、いくつかの案件には対応せざる終えません。「アプリはリニューアルして良くなったけど、その間にユーザーが離れてました」では本末転倒です。腰を据えて新しい技術を習得する上では、これらの細々とした案件が障害となり、リニューアルプロジェクトを停滞させてしまいます。明らかにエンジニアの手が足りなくなり、「バリバリ手を動かしてタスクを片付けてくれる人が欲しい!」と切望した時、奇跡が起きました。何と、若手のWebエンジニアの入社が1ヶ月たらずで決まったのです。2名同日入社!この時、採用に力を貸してくれたのはTECH::EXPERT(テックエキスパート)さん。迅速すぎる対応で、募集開始〜入社までが1ヶ月を切るという異例のスピード採用でした。tech-camp.inテックエキスパートについてざっくり説明すると「エンジニアに転職したい未経験者をみっちり育ててIT企業とマッチングする」というものです。業務経験のないエンジニアをある程度教育する必要はありますが、何より「エンジニアとして働きたい」というモチベーションの高いメンバーを採用することができます。ここで入社した2人はその後、1人はリニューアルプロジェクトのバックエンドチームに参加しGoでAPIをバンバン実装し、もう1人はリニューアルプロジェクト以外の開発案件をほぼ1人で受け切るなど、それぞれ活躍してくれました。本当にこのタイミングで入ってくれた2人には感謝しています。次回予告さて、リリースを半年後に控えた時点でエンジニアはまだ7名。GoとReactNativeの経験者はまだいません。長くなってきたので、続きは次のブログにて。次回は「怒涛のフリーランス入社ラッシュ」「沖縄からの襲来者(Goエンジニア)」「錯綜する設計、終わらないモブプロ、狂う見積り」などの内容でお送りする予定です。次号を待て!!ハウテレビジョンでは絶賛エンジニア採用中です!ここまで読んで頂きありがとうございます。ReactNativeやGo、Dockerを業務で使ってみたいエンジニアの方がいらっしゃいましたら、ぜひとも一度オフィスに遊びに来てお話しましょう!ご連絡はこちらから。08:00半年でエンジニア4人→12人に急増したチームで、iOSアプリ(ReactNative)とAPI(Golang)を作り直して無事リリースした話(前編)Tweetもっと読むコメントを書く2018-07-11リモートワークをやってみてわかったメリット・デメリットと制度化に必要な工夫リモートワーク導入2ヶ月のまとめリモートワーク。自宅、カフェ、コワーキングスペースなどオフィス以外の場所で勤務する働き方。朝夕の通勤ラッシュに揉まれることなく、オフィスの空調戦争に巻き込まれることもない。自分の好きな場所で、好きな音楽を聞きながら、リラックスして仕事に集中できる。そんなリモートワークがこの5月より弊社にも導入されました。「事前にSlackで申請をすることにより、週2回/月4回までリモートワークが可能」という制度です。実際に2ヶ月体験して感じたメリット・デメリット、そして今後の課題などをまとめました。体験してわかったリモートワークのメリット3つ「サラリーマンの夢=出社しない」を実現なんといってもこれが一番大きなメリットだと思います。毎朝通勤ラッシュに揉まれて、オフィスにつく頃にはヘトヘトでモチベーションもだだ下がり。そんな状況から開放されるのは、サラリーマンの夢だといっても過言ではないと思います。リモートだと当然ですが通勤の必要がありません。朝はちょっと遅めに起きて、ご飯を食べたらシャワーでも浴びて、スッキリとした気分で自室のデスクに向かう。通勤ラッシュという苦行をこなす必要がないので、仕事を始めるモチベーションも上がりますよね。「ちょっといいですか?」に邪魔されないメールチェックやミーティングなども終わり、ようやく仕事に集中しだした頃にやってくる一言。経験ある方もいると思いますが、これをやられるとせっかくの集中力が途切れてしまいます。一度切れた集中力を戻すのは大変。「質問は後にしてくれよ」と思ってる方も多いはず。リモートワークだと、コミュニケーションは基本的にメールかチャットベース。自分の好きなタイミングでチェックでき、集中したいときに邪魔されることはありません。リラックス感が半端ないって誰にも邪魔されることなく、好きな格好で好きな音楽を聞きながら仕事をする。この暑い季節、オフィスで繰り広げられる不毛な空調戦争とももちろん無縁です。そりゃ当然オフィスで仕事するよりリラックスできます。ちなみに私の場合、自宅だったので甚兵衛を着て、スピーカーでBGMを流しながら作業してました。通勤にかかる時間とラッシュによるストレスがなくなります。次に誰にも邪魔されずリラックスできるので、高い集中力を持続させやすくなります。ゆえに作業効率がアップし、仕事も捗ります。逆にデメリットも3つあるもちろんいいことばかりではなく、デメリットもあります。次にあげるようなことが、実際感じた・思ったリモートワークのデメリットです。伝わってる?!コミュニケーションが難しくリモートだと、基本的にメールかチャットなどテキストベースでやりとりすることになります。テキストベースだと、どうしても微妙なニュアンスが伝わりづらく、文章に工夫が必要になります。言葉では簡単に伝えられるのに、文字だと言いたいことが正確に伝わらないというストレスを感じることがありました。対面に比べて伝わる/伝える情報量が少ないので、会議や打ち合わせといったケースは特に対応が難しいかもしれません。現場の温度感・緊急性がわかりづらいテキストベースでのコミュニケーションに起因するものとして、現場の温度感を感じ取りにくいというデメリットもあります。チャットやメールの確認が遅れたりして、結果としてトラブルになってしまうケースも考えられます。煩悩との戦い!高い自律が求められるオフィスとちがって誰も見ていないので、サボろうと思えばいくらでもサボれてしまいます。ゲーム、テレビ、ネットなどオフィスに比べて誘惑はいっぱいあります。「ちょっとくらいいか〜」と気を許したらもうダメです。時間を溶かしてしまいます。誰にも見られていないとはいえ、業務中であるという認識と、誘惑に負けない自律性が必要です。デメリットまとめ文字から伝わる情報は対面と比較して乏しいため、相手に正確に伝えるためには文章表現に工夫が必要になります。口頭でのコミュニケーションとは異なり、リアルタイムにやり取りできないので現場との空気感・緊張感の共有が難しく、後で問題になることも。上記に加え、誘惑に負けないように自分を律する必要があります。誰にでも合う働き方ではないと思います。自室で一人勉強するよりも、友達と勉強したり、自習室にいったほうが捗るといったタイプの人には向かないかもしれません。「ハイブリッド型」のリモート制度がいいのでは?2ヶ月ほど週1回のペースでリモートワークを体験してみて感じたことをまとめてみました。制度としては試行錯誤の段階ですが、私の場合はプラスの面のほうが多かったように思います。確かにどうしてもリモートでは対応できない状況もありますので、フルリモートではなく、週にN回までといったハイブリッド型の制度にするのが良いと感じています。一方でデメリットであげたように、リモートワークというスタイルは誰にでも合う働き方ではないと思います。人や業務によって合う合わないがあると思います。こまめに進捗を報告したりと、やり方を工夫をするなど改善を重ねていくことにより魅力的な制度になっていくはずです。はてなブログPro『外資就活ドットコム』の開発チームです。技術ネタ・プログラミングネタ等々書いていきます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。