Engineer Blogs

No Tech No Life

アプリのアイコン

Engineer Blogsのアイコンはこちらです。
f:id:engineer-blogs:20200609234023p:plain:w100
このアイコン作成にかかった工数は約3人日です。
エンジニアである僕がどういう過程を経てこのアイコンを作ったかを書きます。

アイコンのパターン

世の中に存在するアイコンを調査したところ、大きくこの4つのパターンに分類できると感じました。

  1. サービス名をそのままアイコンに入れているパターン
  2. サービス名の頭文字を入れているパターン
  3. サービスのロゴを入れいているパターン
  4. サービスの内容を表しているパターン

1

サービス名が短い場合に適しています。

https://lh3.googleusercontent.com/JJB3ZAgLIzX6mH4GI33suKrABZL9Uq59V4M19Kk0Ch9n2gpfpu1IAMt6Ujbq8CKJfA https://lh3.googleusercontent.com/rJTUpyV-CpMNmN3QLBgPSOgm-cW5U9YHiIgGiTChzJ3jzAYyIrBdEs-RY8KnUalAAQ

2

サービスの機能が複数ある場合や、サービスが持つコンテンツに統一感がない場合に適していると感じました。

https://image.flaticon.com/icons/png/512/60/60548.png https://lh3.googleusercontent.com/ywcpgVpFFTd5wqMKDse9h82ZRP1Akcmt2C_spjCryoZe9gLb6JVKaQckY1mPX9IQKXY=s360-rw

3

知名度があるロゴが存在する場合や、知名度がある組織が持つサービスに効果的だと感じました。

https://lh3.googleusercontent.com/eLqKK4MkDoXXbD_F3A_2rs-othxTESxbocvyOGyhAmbNCydgnYKczItIY2-HLYJmhr6Q=s360-rw https://92m010.com/13-xpress/wp-content/uploads/2019/04/Twitter%E3%82%A2%E3%82%A4%E3%82%B3%E3%83%B3.jpg

4

サービスの機能がしぼられている場合に効果的です。

https://lh3.googleusercontent.com/lMoItBgdPPVDJsNOVtP26EKHePkwBg-PkuY9NOrc-fumRtTFP4XhpUNk_22syN4Datc https://lh3.googleusercontent.com/POgn4x_Jrz18VxrjbZC88ijwZJwmOjs2flX1KC0Kz7IF1oncFoKOMsWfFKntJjc20BRJ

1-4のパターンのうち2か4が適していると思いましたが、各社のエンジニアブログがまとまっていることを表すアイコンを作成することができなさそうなので、2を選びました。

Keynoteでサンプルを作成

使い慣れているKeynoteを使ってサンプルを作成しました。
こんな感じです。
f:id:engineer-blogs:20200612194741p:plain:w50

背景色を変えたり、イラストの色を変えたり、イラストの形を変えたり色んなパターンのサンプルを作成しました。
イラストはEngineer Blogsの頭文字のEとBを組み合わせています。
f:id:engineer-blogs:20200612200241p:plain:w100 f:id:engineer-blogs:20200612200932p:plain:w100
複雑なイラストを作成するのは難しいのでシンプルなイラストにしています。

XDを使ってアイコンを作成

作成したサンプルを元にXDを使ってアイコンを作成しました。SVGでダウンロードし利用しています。
またアプリ内で使う通知アイコンやスプラッシュ画面のアイコンなども同時に作成しました。

最後に

シンプルなアイコンだと作成することは難しくなかったです。
また、アートはセンスの比重が大きいですが、デザイン(設計)は論理的な思考の比重が大きいと改めて感じました。

AWS CDKでインフラ構築する際のメリットとデメリット

Engineer BlogsではバックエンドにAWSを利用しています。
インフラをAWS CDK(Cloud Development Kit)を利用し構築しました。

AWS CDKとは

AWS上にインフラを構築する場合、ServerlessFramework、Terraform、CloudFormation、手動など色々な手段が存在します。
AWS CDKもインフラ構築を目的としたツールキットです。
https://docs.aws.amazon.com/cdk/index.html

AWSに構築したいリソースをプログラミング言語で定義しデプロイできます。
CloudFormationなどを用いるとJSONYAMLを書く必要があります。細かい設定や複雑な設定が必要な場合JSONYAMLが読みにくくなります。その結果ミスに繋がりやすくなり保守性が低くなります。
AWS CDKを用いるとこのような煩わしさがなくなります。

メリット

AWS CDKを用いる際のメリットです。

メリット1、プログラミング言語による定義

テンプレート(JSONYAML)ではなくプログラミング言語(TypeScript、JavaScriptPythonJavaなど)で定義することによるメリットです。

  • ビルド時にミスがある場合エラーとなり、エラー個所もわかりやすいので、手早く修正できる
  • オブジェクトとして分割できるので、再利用性に富む
  • IDEを利用する場合、IDEの恩恵を受けることができる。

例えばLambda関数はこのように定義できます。

makeGetAllCompanies(stack: EngineerBlogsStack) {
    return new lambda.Function(stack, 'getAllCompanies', {
        code: lambda.Code.fromAsset('lambda/company'),
        handler: 'companyHandler.getAllCompaniesHandler',
        runtime: lambda.Runtime.NODEJS_12_X,
        environment: {
            TABLE_NAME: TableName,
            REGION: 'ap-northeast-1'
        },
    });
}

メリット2、スタックによる管理

定義したリソースはcdk bootstrapをすることでCloudFormationのテンプレートがローカル上に作成されスタックとして管理できます。
例えばcdk listをすると作成済みのスタックをリスト表示できます。

そしてcdk deployをするとクラウド上にデプロイできます。
デプロイ後にローカルでリソースの定義を変更すると、cdk diffで差分を確認することができます。
例 : 上記のソースコードruntime: lambda.Runtime.NODEJS_12_Xruntime: lambda.Runtime.GO_1_Xに変更した場合

$cdk diff
Stack EngineerBlogsStack
Resources
[~] AWS::Lambda::Function getAllCompanies getAllCompaniesF8157CDF 
 └─ [~] Runtime
     ├─ [-] nodejs12.x
     └─ [+] go1.x

このように差分を確認できます。

メリット3、Lambdaのロジックのデプロイ

APIやバッチなどの処理を担うLambdaのロジックをcdk deployでデプロイすることができます。

デメリット

AWS CDKを用いる際のデメリットは特にないと感じました。
しかしもともとプロジェクトでCloudFormationなどでリソースを定義している場合、コストがかかることがデメリットとなりそうです。
移行とAWS CDKの学習にコストがかかります。

最後に

こちらのWorkshopに沿って進めると理解しやすいと思います。僕は闇雲に進めたのでしんどかったです。 cdkworkshop.com

困った時はこちらが参考になります。

Engineer Blogsをリリースしました

Engineer BlogsというAndroidアプリをリリースしました。
様々なIT企業が公開しているIT技術に特化したブログ(エンジニアブログ)の記事をまとめているアプリです。

Google Play Store
play.google.com サンプル動画
www.youtube.com

背景と目的

エンジニアブログとは

運営しているサービスやIT技術に特化した内容を記事として公開しているブログです。
IT企業だけでなく、個人でエンジニアブログを持っている方もいます。
IT企業が運営しているエンジニアブログは、運営しているサービスや事業に特化した記事が多く具体性があるため興味深いです。

Engineer Blogs作成の背景

複数のIT企業のエンジニアブログがまとまってるサービスがなく、不便だと感じていました。
そこで、私が興味のあるエンジニアブログだけがまとまってるAndroidアプリを個人用に作りました。
友達にそのアプリを見せたところ、リリースを勧められリリースしました。
すると、ブラッシュアップしたい衝動に駆られ設計から見直して実装し今のEngineer Blogsとなりました。

Engineer Blogsの目的

  • ユーザーが興味のあるエンジニアブログを読みやすくすること
    複数の企業のエンジニアブログの記事を収集し、ユーザーが選択した企業のエンジニアブログを配信することで、複数のエンジニアブログを読みやすくしています。
  • ユーザーが未知のエンジニアブログに出会うこと
  • バズらない記事もユーザーに届けること

詳細

Engineer Blogsの機能を紹介します。

一覧表示

選択した企業が上部にタブとして表示され記事が縦に一覧表示されます。
表示されている記事をタップすると記事の内容が表示され読むことができます。
f:id:engineer-blogs:20200604224514p:plain:w400

過去の記事と新着記事

過去の記事

下部に表示されている「もっとみる」を押下すると過去の記事が表示されます。

新着記事

新着記事が投稿されると通知されます。
選択中でない企業の新着記事も通知されるので、気になる場合は企業を選択し直すことでその新着記事を読むことができます。

お気に入り

何度も読み返したい記事や、後で読みたい記事をお気に入りとして保存できます。
f:id:engineer-blogs:20200604230039p:plain:w200

並び替え

タブとして表示されている企業の順番を並び替えることができます。
f:id:engineer-blogs:20200604234618p:plain:w200

今後

Engineer Blogsの今後

Engineer Blogsの目的を軸として機能追加や機能改善をする予定ですが、具体的な施策を思いついていません。
ユーザーからのレビューなどを元に試行錯誤します。
(Kotlin/Nativeを用いてAndroidiOSの共通ロジック作成し、iOSアプリをリリースしたいです。)

このブログの今後

Engineer Blogsを作成するまでの流れを技術的な観点で記事を書いていく予定です。
興味のある方はウォッチしていただけると嬉しいです。
疑問、間違いの指摘、感想などがあれば気軽に投げてください。