zeplinへ愛を込めて

はじめまして、Praha Inc.デザイナーです。
この記事では、みんな大好きzeplinについて愛をしたためます。

Zeplinとは、デザイナーと開発者をつなぐ強力なコラボレーションツールです。 デザインをアップロードすることでマージンやカラーなどの情報を抽出したり、スタイルガイドを制作することができます。 

そんなZeplinの好きなところを語らせてください。

多くの主要デザインソフトに対応している

「案件・クライアントによって使用するデザインソフトは異なるけど、デザインを一括で管理したい…」

zeplinなら、Sketchはもちろんのこと、 Photoshop や XD、 figma にも対応しているので、デザインを一括で管理することができます。また、プラグインを設定を行えば、各ソフトの UI からダイレクトにファイルのエクスポートができるので、作業を止めて別のソフトを立ち上げる必要はありません。

ヒストリーが見やすい

アップロードしたデザインの履歴がかなり分かりやすいです。

デスクトップアプリでしか使用できないのですが、便利だなと思っている機能は過去のデザインを透過させることができる機能です。

これを使うことで、新しいデザインの上に重ねて差分を探すことができます。 特に実装と並行してデザイン作業を行うときに、エンジニアたちに「どこが変わったのか」 と聞かれても 一瞬で変更箇所が分かります。画像は文言の変更前後で重ねて見た様子。

画像の書き出しが楽

画像制作時にアイコンを指定することで、だれでもpng/jpg/svgで2倍3倍の画像を書き出すことができます 。頻繁に発生する「あの画像書き出しといて」という 無駄なやり取りの往復を減らすことができます.。

デスクトップアプリの細かいUX

デザイン 一覧からドラッグアンドドロップするだけで画像をフォルダにコピーできたり、 文言やURLのコピーがワンクリックで済んだりと、 かゆいところに手が届くような体験が提供されています。

簡単にデザインシステムを構築することができる（らしい）

実はまともに使ったことがないのですが、シンボルをアップロードすることで、zeplin上で コンポーネントの管理をすることができるそうです。 各デザインのプレビューでシンボルを選択すると何のシンボルが使われているかが表示されます。 エンジニアが実装する際に既存コンポーネントを使い回しやすくなりますね。 

👆👆👆👆👆👆👆👆👆👆👆👆
ここまでが愛で、ここからが愛ゆえの要求（デメリット）です。
👇👇👇👇👇👇👇👇👇👇👇👇

スマホでプレビューできない

figma や XD と比べて弱い点として、スマートフォンでのプレビュー機能がないことがやや死活問題でした。 iOSもアプリを会社で製作している時は、その場で sketch Mirror を使って確認することで事足ります。 しかし、私用のスマホが Android のため、 Sketch で作ったモバイル UI を実機で確認しようとした時にsketch Mirror も使えず、 invisionを使用しました。 Zeplinを使ってスマホでプレビューできるようになれば動き以外大体完結するのに…。

------

小規模チームでのやり取りはもちろんですが、特に中〜大規模サービスで使用すると真価を発揮できるZeplin。私はで画面のデザインだけではなく、アイコンの一覧化やイラストの整理としても使っています。zeplin号のネーミングセンスもアイコンもキュートでグッド。

以上、最近はFigmaを使った制作も楽しいデザイナーのzeplinへの愛を語る回でした。

ピザとお酒とLT合戦

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして。Praha Inc.の社長兼エンジニア、松原です。

「3月1日」

これが何の日かお分かりでしょうか。

正解です。PrAhaで初めてピザパーティが行われた日です。

知名度で圧倒的に劣るスタートアップでもピザを配れば人が来てくれるのではないか、と淡い期待を抱いてこんなイベントを作ってみました。

connpass.com

参加者に無料でピザとお酒を振る舞うことで、AIDMAモデルで言うところのAttention, Interest, Desireは全部ピザにアウトソーシングします。たらふく食べた後はPrAhaメンバーによるLT3連発と、触発された方が自由にその場でLT登壇できるセッションを用意しました。

当日の様子はこんな感じです：

https://en.wikipedia.org/wiki/Pizza

ごめんなさい、話すのと食べるのに夢中で写真を撮るのを忘れてしまったので、イメージ画像だけ貼っておきます。

LTその1：PrAhaについて

僕がプレゼンしている間、4人も社員が居たのに誰も撮ってくれませんでした。悲しい。なんて撮れ高の少ない会でしょう。代わりに僕のアイコンでも貼っておきます。

肝心のプレゼンではPrAhaのプロジェクトを紹介したり、海外展開やVCとの協業の取り組みや、社内制度の紹介を行いました。この記事では社内制度を一つだけ紹介します：

 

毎月10万円の研究開発費について

PrAhaでは全ての従業員に毎月10万円の研究開発費を支給しています。理由は「製作者の熱意に水を差したくないから」です。

良いモノを作るにはお金が要ります。調査費用、awsのインスタンス代やapiの利用料、専門家との提携や広告宣伝費、人件費、などなど。

普通の会社であれば、会社のお金を使うためには様々なプロセスを経ます。

上長を説得するために話を組み立てたり、パワポを作ったり、MECEにしたり、「それお金になるの？」と聞かれてオドオドしたり、許可が降りたら申請書を書いて、上長・上々長・上々々長の承認を待って、支払いコードが違うと差し戻されたり。まぁ色々あって運がよければ1ヶ月後にはお金が使えるようになるのではないでしょうか。

その頃には作り手の意欲は削がれています。

なんでモノ１つ作るのにこんな面倒なプロセスを経なきゃならんのじゃ！と苛立つわけです。

PrAhaはモノづくりが好きな人が集まる会社であって欲しい。

そんな会社が、費用申請みたいな事務作業で作り手の意欲を削いで良いはずがない。

そう考えた結果、全員に毎月10万円を渡して好きに使ってもらう事にしました。

あと人間というのは不思議なもので、自分のお金を使うのは気が引けるかもしれませんが「会社のお金」と思った瞬間、湯水のように使いたくなりますよね。

「ちょっと気になってたけど買うほどじゃないな」と思っていたモノを「会社の金だから買ってみるか」と手に入れたら思った以上に気に入ってしまい、使っているうちに新しいアイデアが生まれる。

こんなセレンディピティにも期待しています。

・・・みたいな会社説明をしてました。

話した内容を全部ココに書くとロードオブザリングみたいな長さになってしまうので、もっとPrAhaの事が知りたい人はwantedlyの会社ぺージへgo！

www.wantedly.com

LTその2：tellusプロジェクト（大関）

これまでJAXAなど一部の組織しか使えなかった人工衛星データを誰でも使える分析基盤を開発する「Tellus」プロジェクトの一員として、PrAhaでは雪質解析アプリケーションや、衛星画像を用いたゲームを制作しました。

sorabatake.jp

sorabatake.jp

そのプロジェクトの開発手法や技術構成などを説明しました。

これは余談であるが、僕は小学生の頃から宇宙に関わる仕事がしたくて大学でも宇宙工学を学びました。しかし紆余曲折があり宇宙から遠ざかっていた自分が、ここにきてようやく宇宙に関わる仕事ができた事に不思議な縁を感じています

LTその3：botプロジェクト（篠原）

話題に挙げておきながらごめんなさい、このプロジェクトは現在進行中で書ける事が非常に少ないのです。LTでも関連技術の説明がメインだったので、内容が気になる方はコチラをご覧ください・・・！

praha-inc.hatenablog.com

ここで一旦PrAhaのLTは終了したので、お開きかと思いきや・・・

一緒にお仕事をさせていただいているA1A株式会社のエンジニア、@mncさんが飛び込みLTをしてくれました！

www.a1a.co.jp

マルチテナントアーキテクチャに関するLTで、濃厚な内容に参加者が前のめりになっていました。マルチテナントにおいては通常テナント間の情報のやりとりは分離されますが、今回のプロジェクト特性上テナントを分離しつつ、かつ一部情報を相互にやりとりする必要が生じるため、どんな技術課題に直面したのか共有いただきました。

さて今度こそLTは終了かと思いきや別の参加者からも飛び込みLTが！

映画「イミテーションゲーム」で一般知名度が向上したであろうアラン・チューリングの半生を詳しく解説いただきました。アラン・チューリングがフルマラソンを2時間台で走れるなんて知らなかった。

ここで長かったLTセッションが無事終了。

僕は途中で帰りましたが、残った方々で残飯を肴に深夜まで飲み続けたそうです。やっぱり金曜日って良いですね！

そんなPrAhaではエンジニア・デザイナーを大募集！深夜までお酒を飲めなくても全く構わないので、少しでも気になった方はぜひお声がけください。

またピザパ開催するので遊びにきてね〜

www.wantedly.com

AWS Lambda(for Ruby2.5)で画像合成をやってみた！

はじめに

株式会社プラハ(PrAha)のエンジニア、篠原です。

AWS re:Invent 2018で、AWS Lambda(for Ruby2.5)がリリースされましたね！

早速使ってみました。

AWS Lambda(for Ruby2.5)の詳細はこちら↓ https://aws.amazon.com/blogs/compute/announcing-ruby-support-for-aws-lambda/

今回はAWS Lambda(for Ruby2.5)で、画像に任意のテキストを合成するデモをハンズオン形式で共有します！

AWS Lambdaで合成した画像↓

今回の記事のリポジトリはこちら↓

https://github.com/praha-inc/composite-image-ruby25

想定読者

• AWS Lambdaを知っている、もしくは使ったことがある人
• AWS Lambdaを使ったことがないRubyist(これを機に使ってみましょう！）
• AWS Lambdaで画像合成をやってみたい人
• AWS Lambdaを使ってみたい人
• 株式会社プラハに興味がある人

ん？プラハってなんだ？という方はこちらへアクセス！ https://www.praha-inc.com/ Wantedlyもやっています！https://www.wantedly.com/companies/praha-inc

準備

AWSアカウントを持っていること

AWS Lambdaとは

公式: https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html

簡潔にまとめると、自分の書いたプログラムを任意のタイミングで実行してくれるサーバです。

AWS Lambdaには無料枠があります。

1,000,000 件のリクエスト
400,000GB秒

(2019年2月15日現在)

単純に考えると

• 100万件のリクエストを並列に捌ける
• メモリ(RAM)1GBのPCが400,000秒動作する

上記のマシンを毎月無料で扱うことができます。 参照: https://aws.amazon.com/jp/lambda/pricing/

割り当てるメモリ量は関数に応じて変更可能です（最小128MB~最大3008MB)。

無料で画像処理のみ行うマシンが欲しい場合、これで十分なのではないでしょうか。

AWS Lambdaを使用するユースケース

例えば、以下のようなユースケースが考えられます。

Heroku(APIサーバ)からLambdaを実行し、結果を受け取るようなケースです。

Herokuのスペックは無料枠だとRAMが512MB(2019年2月20日現在)。

そこで、画像合成の処理のみをLambdaに委譲し、Herokuの負担を抑えられることが期待できます(要検証)。

画像合成をするLambda関数を作る

では、Ruby2.5で画像処理を行うLambda関数を作ってみましょう！

Lambda関数を作成する

AWSマネジメントコンソールのLambdaにアクセス

https://ap-northeast-1.console.aws.amazon.com/lambda/

Lambda関数を作成しましょう。

入力項目	設定値
名前	CompositeImageRuby25
ランタイム	Ruby2.5
ロール	既存のロールを選択
既存のロール	lambda_basic_execution

関数を作成ボタンを押下。

作成したLambda関数の詳細ページが表示されます。

また、作成したLambda関数はCloudWatchLogsにアクセス可能なことがわかります。

画像合成後のファイル保存先のS3バケットを作成する

AWSマネジメントコンソールからいい感じにぽちぽちっと。 https://console.aws.amazon.com/s3/home?region=ap-northeast-1

※ここで作成したバケット名は、後述するプログラム上で扱います。

画像合成プログラムの実装

お好みのエディタを立ち上げて、まずはLambdaで実行するプログラムを書いていきます。 プロジェクトのディレクトリ構成は、先程示したリポジトリを参照して下さい。 (再掲)https://github.com/praha-inc/composite-image-ruby25

Rubyはバージョンを2.5系を使用してください。 (バージョンが違う場合、Lambda環境で実行できない可能性があります）

環境構築

$ mkdir composite_image_ruby25 && cd composite_image_ruby25
$ gem install bundler
$ bundle init
$ vim Gemfile

source 'https://rubygems.org'
gem 'aws-sdk-s3'
gem 'mini_magick'

$ bundle install --path vendor/bundle

画像合成プログラムからAWS S3へPutするための認証周りの設定

$ direnv edit . // direnvを使用していない場合は.env.copyを参照して環境変数を設定してください
$ direnv allow

export AWS_ACCESS_KEY_ID=AWSマネジメントコンソールで発行したID
export AWS_SECRET_ACCESS_KEY=AWSマネジメントコンソールで発行したSECRET

画像合成プログラムを書く

任意のテキストの画像合成後、S3に画像をアップロードします。

require 'aws-sdk-s3'
require './image_helper'

def lambda_handler(event:, context:)
  s3 = Aws::S3::Resource.new(region: 'ap-northeast-1')
  bucket_name = 'YOUR_BUCKET_NAME'
  file_name = 'helloworld.png'

  # Upload Image to S3
  file = ImageHelper.build(event['message']).tempfile.open.read
  s3.bucket(bucket_name).object(file_name).put(body: file)

  # Get Image from S3
  object = s3.bucket(bucket_name).object(file_name)
  {
    statusCode: 200,
    url: object.public_url,
  }
end

# for exec local
if __FILE__ == $0
  lambda_handler(event: { 'message' => 'Hello, PrAha!' }, context: nil)
end

ローカルで実行

$ bundle exec ruby lambda_function.rb

AWSマネジメントコンソールのS3を参照して画像がアップロードされていることが確認できればOK

画像合成プログラムをAWS Lambdaにデプロイ

ローカルからAWS Lambdaにデプロイするための設定をする

先程取得した、AWS_ACCESS_KEY_ID、とAWS_ACCESS_SECRETをaws-cliの設定ファイルに記述します。

$ aws configure
AWS Access Key ID [****]:
AWS Secret Access Key [****]:
Default region name [ap-northeast-1]:

ローカルからAWS Lambdaにデプロイ

aws-cliの設定後、プロジェクトディレクトリのルートで下記を実行し 先程作成したLambda関数(CompositeImageRubuy25)にデプロイします。

$ zip -r function.zip lambda_function.rb image_helper.rb assets vendor
$ aws lambda update-function-code --function-name CompositeImageRuby25 --zip-file fileb://function.zip
{
    "LastModified": "2019-02-20T10:14:42.632+0000",
    "Version": "$LATEST",
    "Runtime": "ruby2.5",
    "FunctionName": "CompositeImageRuby25",
    "CodeSize": 5658411
    ...略
}

動作確認

AWSマネジメントコンソールで先ほど作成したLambda関数を開いてください。

デプロイに成功すると恐らく以下のように表示されていると思います。

テストを実行

テストを行う前に、AWSマネジメントコンソールの右上からテストイベントの設定を行います。 「テストイベントの設定」を押下してください。

テストイベントの設定で以下のように入力してください。 入力後、作成を押下。

作成後、「テスト」を押下してください。

恐らくエラーが発生するので後述の章で対処していきましょう。

エラーの対処

タイムアウト時間の設定

以下のようなエラーが発生する場合

Lambdaの実行時間が足りないので、基本設定でタイムアウト時間を10秒にしましょう。

再度、「テスト」を押下してください。

S3への書き込み権限の付与

以下のようなエラーが発生する場合

LambdaからS3への書き込みをする権限がないため、書き込みを可能にするよう権限を付与します。

LambdaからS3へのアクセス権を付与する

「実行ロール」を確認してください。

「実行ロール」からカスタムロールの作成を押下。 ページが表示されたら、任意のロール名を入力（ここでは lambda_write_s3)。「許可」を押下。

作成後、以下のように表示されます。

「lambda_write_s3」をクリックし、「ポリシーをアタッチします」を押下してください。 「AmazonS3FullAccess」にチェックボックスを入れて、ポリシーのアタッチを押下してください。

AWS Lambdaのマネジメントコンソールに戻り、ロールを新規に作成したものに変更し、右上の保存を押下してください。

以下のように表示されればOKです(LambdaからS3へのアクセス権が付与されたことがわかります)。

再度、「テスト」を実行

実行に成功することを確認します。

最後に、画像がS3にアップロードされていることが確認できれば完成です！

おわりに

今回はAWS Lambda(for Ruby2.5)で画像合成を行いました。いかがでしたでしょうか。 Lambdaを使ったことがない人、Lambdaで画像合成をやってみたい人の参考になれば幸いです。

不明点、指摘点などありましたらコメントをお待ちしております！

次はAWS Lambdaで動画合成をやってみた、を書く予定です！

Happy Coding!

いきなりスカッシュ

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして、Praha Inc.の社長兼エンジニア、松原です。

4年間働いたリクルートを退職して今はスカッシュをしています。

最近この前振りがパターン化してきた気がします。

 

 

 

みなさん、スカッシュというスポーツをご存知でしょうか？

僕は最近初めてこのスポーツを知りましたが、要は四方を壁に囲まれた状態で行うテニスです。壁に向かって黒いゴムボールを打ち付けて、床に2バウンドする前に壁に打ち返します。先に横の壁を打ってもよし、なんならピンボールみたいにボコボコ壁をバウンドさせても良い。打球の不規則な軌道を予測する感覚が他のスポーツとは大きく異なり、今やPrAhaは社員の８割がスカッシュ経験者という空前のスカッシュブームが起きています。

 

（社内slackで異彩を放つsquashチャネル）

 

 

PrAhaは出社時間も退社時間も自由な会社なので、15時くらいに一度仕事を切り上げて、スカッシュをして、汗を流してから仕事を再開することにしました。

こんな感じで、スカッシュコートは四方を壁に囲まれています。左上の小さな点がゴム製のスカッシュボールです。テニスやバドミントン等のラケット競技は力任せに叩くと簡単にアウトになってしまいますが、スカッシュボールは思いっきり壁に打ち付けても思ったほど弾まないので、全力でぶっ叩けます。日々のストレス解消になりますね！

 

ただ写真を見てお分かりいただけると思うのですが・・・

 

狭い密閉空間を肉体的ピークに達した成人男性2名が鈍器を振り回しながらダッシュするスポーツなので、割と危険です。スカッシュボールが背後から耳を掠めてカッ飛んでいく度に「もう少し上手い競技形態があったのではないか？」と疑念が止まりません。

ちなみに僕は写真右側の大関くんに顔面をラケットで強打されて悶絶しました。本人は「ヒッハハー！ごめんなさい！」って笑ってたけどアレは本当に痛かった

 

（オーストラリアンフォーメーションを試したり） 

 

壁際を攻められて苦しんだり（壁スレスレに打たれると、まず返せない） 

 

（五感を奪われたり）

スポーツの締めくくりはジャグジー！

こんな感じで汗を流したあとは施設備え付けのジャグジーでサッパリ！体は完全に寝る準備が整っていますが、まだ17時台なのでココから仕事再開です。

 

明るいうちにスポーツを楽しんで、風呂に入ってから、好きな時間に仕事に戻れる。自分たちの会社を作ってよかったな〜、と思う瞬間の一つです。

リクルートを退職、起業して看板も作っています

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして、Praha Inc.の社長兼エンジニア、松原です。

4年間働いたリクルートを退職して、今は看板を作っています。

意味がわからないと思うので、細かな経緯はコチラをご覧ください

さて、オフィスの一部をコワーキングスペースとして運営し始めたわけですが、このスペースには致命的な欠点がある事に気づきました。

どこにあるか分かりづらいのです。 

Cowork Prahaの住所は「新宿区舟町１０−１７」なのですが、そのままgoogle mapで開くとココに飛ばされます

でも実際の住所は四谷コーポ、つまりコッチなんです

めちゃくちゃ分かりづらいです。

しかもCowork Praha、中身はこんな感じでゴージャスなんですが

建物の外観が、割と地味です。

ここの4階です。若干バルコニーっぽい雰囲気が出ていますが、この外観を見て「あ、これコワーキングスペースだ！」と気づく人は多分居ないので、大家さんの承諾を得て看板を設置する事になりました。

ちょっと短足気味なダックスフントみたいな可愛い看板が届きました。

ついでに液体チョークも買ってみました。見た目はホワイトボードに使うようなペンなのですが、乾くとチョークのような粉っぽい触感になります。

Praha Inc.にはデザイナーも居るので本来なら素晴らしくオシャレな看板が仕上がるはずなのですが、あいにく今日は不在なので僕がペンを取ります。

ちなみに僕にはデザインの才能がありません。良かれと思って自社サービスにローディング中のアイコンを追加したら翌日には消されていました。

「突然10年前のデザインが紛れ込んでいて驚いた」「数ある中からアレを選んだのは逆に凄い」と酷評されたので、今回は消されないことを祈りながらペンを滑らせます。

すでに斜め下に字が傾いている気がします。

大事な情報を補足しておきます。Cowork Prahaは4階ですよ〜！残念ながらエレベーターがないのですが、足の筋肉は刺激されます。

営業時間は月・火を除く11時〜21時です。稀に貸切イベントなどがあるので、最新情報は常にチェケラです。

僕もwebに関わる人間の端くれ。差し色が重要だということは理解しているので、赤を入れます。

完成！これで迷わずにコワーキングスペースにたどり着けるようになったぞ〜。

唯一気になるのは、完全にゴミ捨て場に設置してしまったことです。明日には捨てられてそうで心配です。矢印を書き直して別の場所に移そうとしたのですが、チョーク落とせませんでした。

裏面に書き直せば？と思われるかもしれませんが 

裏面は遊び心で埋めてしまったのでキャンバスの余裕がありません。やらなきゃよかった。でも今後は教会のように週替わりメッセージを書いておくので、「今日は何て書いてあるのかな〜」と気になった方はぜひCowork Prahaに遊びにきてください！

冬は扉を閉め切ってるので、入り口はこんな感じになっています。室内の様子が見えないと開けるのが怖いと思いますが、中は優しい人ばかりなので大丈夫です！近々ちゃんと入り口に「PrAha」みたいなシール貼っておきますね。

Cowork Prahaを運営するPraha Inc.では看板制作の他、スタートアップに特化したwebサービスの企画・デザイン・開発を担う方を募集中！ぜひ気軽に話を聞きに来てくださいね〜

incpraha@gmail.com

リクルートを退職、起業して本棚を作っています

*このブログではPraha Inc.の社員の様子、仕事ネタなどをお伝えします。

初めまして、Praha Inc.の社長兼エンジニア、松原です。

4年間働いたリクルートを退職して今は本棚を作っています。

多分意味がわからないと思うので補足すると

リクルートでは新規事業企画とエンジニアとしてiOSアプリ、webフロントエンド/サーバサイドの開発等を担当していました。2019年の1月に退職。WEBサービスの企画・デザイン・開発をスタートアップに特化して提供する会社を友人数名と起業しました。こんな会社です。

そこで皆が入れるオフィスを探し始めたのですが、せっかく独立したんだし、やっぱりオシャレなオフィスで働きたい。でも値段は抑えたいのでオフィスの一部をコワーキングスペースとして運営する事にしました。こんなコワーキングスペースです。

せっかくなので僕らが読み終わった技術書などを自由に読めるようなフリー本棚を作ることにしました。「エンジニアが3人も居れば一瞬で終わるだろう」と炎上するプロジェクトのPMのようなことを考えながら本棚の梱包を解いていきます。

いきなり破損した部品が出てきました。非常に幸先が悪い。独立した初日、初めて届いた本棚に最初からヒビが入っている状況に出鼻を挫かれつつも、人目につかない底部の部品だったので気にせず組み立てます。

この辺で気づいたのですが本棚を組み立てるのとWEBサービスを作る工程には似た部分が多いように思います。

まず、クライアントの仕様書を理解するところから始めます。

エンジニアや関係者を集めて「この部品は天板に差し込むのでしょうか？」「いえ、これは底板です」「なるほど」とお互いの理解をすり合わせながら本棚全体の仕様を整理しつつ、実装レベルに作業イメージを分解します。

分解が完了した作業から分担して着手します。今回は部品を繋ぎ合わせる「ジョイナー」を差し込む人と、ネジを締める人に分かれて各々の作業を進めていきます。

僕はパレートの法則（組織の利益は全体の２割が生み出していて、残りはサボっている）を遵守すべく、撮影したりチョコを食べたりしました。

徐々にコンポーネントが仕上がっていきます。

職人気質なエンジニアはこの辺りでリファクタリング（動作に影響は無い範囲でコードの内部構成などを整理する）をしたり、テストコードを増やします。ネジを増し締めするイメージですね。

スタートアップのプロジェクトでは軽視されがちですが、テストコードは大事です。時間が無いから、今はスピード重視だから、とテストコードを書かないと必ず後でバグに工数を取られて、結果的に開発スピードが落ちます。

「スピードを重視する時こそテストコードを書くべきですね」

ネジを増し締めする手に力が入ります。

最後はコンポーネントを繋げて、サービスローンチです！ここまでの努力を振り返りつつ、自分たちを精一杯褒めてあげましょう。

Praha Inc.では本棚のみならずスタートアップのWEBサービスをデザインから開発まで一貫して提供しています。アイデアはあるけど作れる人が居ない、そんな方は気軽にご相談ください！

そしてエンジニア・デザイナーも積極採用中です。あなたの才能を本棚作りで開花させませんか？

incpraha@gmail.com