FreeStyleVision

はじめに

今回はFlutterのwidget管理において、個人的にこれが答えだ！
と思うものを見つけたので、この技術について学習した内容を、
ハンズオン形式でお伝えします。

WidgetBook

もったいぶってすみません、その技術とは、「Widgetbook」のことです。
Widgetbook　→　Widgetbook (docs.page)
こちらのWidgetbookを使うことで、アプリ内で使用されているそれぞれの
widgetをカタログ形式で参照することができるライブラリです。

Widgetbookでできること

・実装したwidgetを視覚的に確認できる。
　基本的にコードベースで作成したものは、実行してみるまでその実態を
　確認できません。しかし、Widgetbookは、ツールを立ち上げるだけで
　全てのwidgetを表示することが出来ます。
　このメリットを活かして、お客様にデザインの確認を依頼することが
　出来たり、メンバ間でwidgetの共有が容易になったりします。

・widgetを階層化して整理することができる。
　Widgetbookのカタログでは、閲覧するためのメニューがありますが、
　このメニュー内のwidgetをフォルダにまとめたり、整理することが
　出来るので、カラーごとに分けたり、種類ごとに分けたりと、集計や
　管理が容易になります。

・デバイス設定を反映させた見た目を確認できる。
　基本的にはブラウザでそのカタログを開くこととなるWidgetbookで
　あるが、カタログのBuilderでAddonのオプションを設定することで
　簡単にライトモード/ダークモードの見た目を確認できます。

Flutterとは？

通常、モバイルアプリを開発するには、swiftでiOSを、javaやkotlinで
Androidを開発しますが、クロスプラットフォームで開発できるものも
存在します。
その一例がFlutterです。同じコードでiOS,Android,Windows,MacOSなど、
様々なプラットフォームで動かすことができます。
他にもReactNativeなど、クロスプラットフォーム開発が可能な技術も
ありますが、Flutterを触ってみて、採用するメリットをまとめました。

コミュニティについて

Flutterは、ご存知の方もいらっしゃるかもしれませんが、「Flutter大学」
という巨大なコミュニティが存在します。Flutter技術者がLTを実施したり
情報共有をする場として重宝されています。
また、その他でもGit Hubでプルリクエストが活発であったり、
全体的に言語のコミュニティが盛り上がっているので、開発の最中に
参考にできる材料が豊富で、開発しやすいです。
ReactNativeやKMMもクロスプラットフォーム開発の検討にあがりますが、
教育コストの面や、コミュニティの大きさ等で、Flutterを採用するのが
いいと感じました。

はじめに

今回はFlutterを使って通知を送る方法をまとめました。通知が送れると、
アプリを開かなくても状態が確認出来るので、スマホアプリ開発の技術
として重宝されています。

導入

今回はシンプルに画面に通知ボタンを配置し、ボタンを押すと通知が来る
アプリを作りました。

はじめに

表題の通り、FlutterのWebView機能を使ってみようと思います。
まず、FlutterとはDart言語で構成されるアプリケーションのUIキットの
ようなものです。豊富なデザインやアイコンなどがあり、簡単に、かつ
綺麗にアプリ開発をすることが出来ます。
そんなFlutterですが、1からボタンやテキストを作るだけでなく、
Webサイトをアプリ内で表示するWebViewも提供されています。

なぜわざわざFlutterでWebViewを使うの？

Flutterはアプリケーションを開発することが出来るので、
Web Viewの登場機会といえば、動画の埋め込みなど、
一部の用途でしか使われません。

しかし、こんな使い方もあります。
モバイルサイトやモバイル版Webアプリをネイティブアプリのように振る舞える。
こちらの使い方です。例えば、すでに運用しているモバイルサイトやモバイル版
Webアプリがあったとします。
しかし、Webアプリではスマホに通知を送ることはできません。
そこでFlutter WebViewの登場です。この機能でモバイルサイトやモバイル版
Webアプリを表示してあげて、通知機能だけ実装することで、わざわざ
ネイティブなアプリに作り替えなくても通知機能を実現することが出来ます。
また、いずれはネイティブアプリにしたいけど、コスト面の問題があり、
一旦最低限の機能を実現するためにFlutter WebViewを使う、という使い方です。
このようにBtoBのビジネスシーンでは、引き合いになりそうな技術のため
今回調査してみました。

はじめに

自身の参画案件において、PythonでCSVを扱うことがかなり多いので、

操作方法の基礎をまとめて記載します。

内容

今回のフォルダ構成は以下の通りです。

Book1.csvの内容は以下の通りです。

フォルダ「csvファイルをまとめて処理」内

CSVの読み込み

まず、csvライブラリを用いずにCSVファイルを読み込むプログラムを記載します。

業務経験を積んでいくと、レビューを依頼する側(レビュイー)から、依頼される側(レビュアー)になります。レビュアーには、経験則から基づく技術力が必要になりますが、人によって技術力に差がでてしまいます。今回は、技術力の差に関係なく、レビュアーの心構えを学ぶことで、レビューによる品質を高めることに繋げたいと思います。

初めに、レビューとは、”成果物の曖昧な点や問題を洗い出すための討議や評論のことを指し、目的や手段・手法が明確になっていること”と言われています。レビュアーの経験則から、曖昧な所を探すのではなく、正しい手法を知ることが大切になります。また、レビューの誤解としては、”会議のようなもの”と認識してしまい、”曖昧な点や問題点の洗い出し”と逸れ、時間がかかったり、”テストの方が効率的”とレビューよりテストを優先してしまうことがあります。

そして、レビュアーで最重要なのは、敬意と礼儀になります。
レビューを受ける人への敬意を第一に意識できず、攻撃的なコメントでは、技術的な正しさや有用性よりも、人格を傷つけ、品質を低下させ、本来の目的を阻害してしまいます。敬意と礼儀を意識しながら指摘することが、目的を達成するための最短経路です。

GoogleのChromiumプロジェクトのレビュー指針、「尊敬に満ちたコードレビュー」を紹介します。
この指針は、”すべきこと”と”いけないこと”を決めています。

お客様へ高品質な製品をより早く提供するため、引き続き設計スキルの底上げを行っています。
今回は最終回のため、これまで行った分析結果を基に、対策として検討した改善案をご紹介していきます。

【なぜなぜ分析の統計】
弊社で発生した設計に関する25件の不具合を例に挙げ、未然に防ぐにはどのような対応を行えばよかったかなぜなぜ分析を実施しました。

≪障害原因の分析≫

上記より、正しい設計やPJ管理を行うことで8割の障害を回避することが可能となります。

お客様へ高品質な製品をより早く提供するため、引き続き設計スキルの底上げを行っています。
そこで前回同様、弊社で発生した不具合を例に挙げ、設計段階で未然に防ぐにはどのような対応を行っておけばよいか、分析結果と併せて記載します。

【事例システム詳細】
休職者支援システムにて、所属上司は所属社員の休職情報を閲覧することができる。

≪休職情報閲覧≫

【不具合内容】
2回以上休職履歴がある社員の休職情報を、所属上司が閲覧できないケースがある。

≪期待する結果≫

≪実際の結果≫

お客様へ高品質な製品をより早く提供するため、引き続き設計スキルの底上げを行っています。
そこで前回同様、弊社で発生した不具合を例に挙げ、設計段階で未然に防ぐにはどのような対応を行っておけばよいか、分析結果と併せて記載します。

【事例システム詳細】
受発注システムで受発注の変更依頼を行った場合、変更依頼されたデータはひとつ前のステータスに戻り、再確認・承認を行う順序となる。

【不具合内容】
「ステータス：3」で変更依頼を行った際、「ステータス：2」に戻らず「ステータス：3」のままとなる。

≪受発注システムのステータスの遷移順≫

≪期待する結果≫

≪実際の結果≫

Linux環境のVersionUpで他部門の方が作成した
Shellの改修を依頼されたときに気づいたことを記述させていただきます。
と言っても構文が悪いや、読みづらいといったことではありませんし、
コメント等も記述されていて比較的読みやすいものでした。

では何が気になったのか？になりますが、
依頼されたShellの改修はコマンドパスの修正でした。
この修正がどういったものかと言いますと、
例えばgrepコマンドですと

GREP_CMD=”/usr/bin/grep”

と定義し、grepコマンドを利用する際は

RESULT=`${GREP_CMD} hoge File`

というように使用する方法を取られていました。

そしてVersionUpでコマンドパスが変わったために
この定義の修正が必要となったという話になります。

この記述の方法が間違いでも、問題があるとは思いませんが、
こういったコマンドパスが変わることは
VersionUPではよくあることですので、あまりこういった定義は行いません。

ではどうするのか？ですが、環境変数を利用します。
Linuxではコマンドのパスが環境変数PATHに設定されていれば、
フルパスで記述する必要がなくなります。
そのため、
PATH=’/usr/bin:/bin’; export PATH
というように環境変数にコマンドが存在するパスを記述することで
RESULT=`grep hoge File`
と利用できるようになります。

コマンドパスが変わっても、環境変数に設定するパスにコマンドが存在する間は
改修が不要になります。
※コマンドのパスが変わることはあっても、
　色々なコマンドの存在するパスは変わることは早々ありません。

今回記述したものはShellですが、Shellに限らずちょっとした対応で改修工数が不要となったり、
次の開発で拡張や改修がしやすいような状態にすることが出来たりすることがあります。
このような点についてあらかじめ軽く頭に入れておくと、
開発のちょっとした改善につながるのではないでしょうか。