ハイコントラストはなぜ必要か
HANDAI JKの石田です。突然ですが、「ハイコントラスト」というワードを聞いたことがありますか? ハイコントラストとは文字通り「コントラストが高い」という意味ですが、では「コントラスト」とは何でしょうか?
(本記事におけるコントラストは色のコントラストを指します。)
そもそもコントラストとは
コントラストとは「色などが並置されているものと著しく異なっていること」であり直感的に言えば、「どれだけ際立って見えるか」ということです。
コントラストが高いものと低いものを比べてみましょう。
黄の背景に青の文字が書かれたものははっきりと読み取ることができるのに対し、あずきの背景に薄紫の文字が書かれたものは注意して見ないと何が書かれているのか分かりづらくなっています。
コントラストの算出方法
色のコントラストは相対輝度というものを使って求めます。詳しく知りたい人はWikipediaの以下のページが分かりやすいです。値は(1:1~21:1)の間になります。
ハイコントラストが有効なケース
「コントラスト」について大体掴んでもらったところで、今度はなぜハイコントラストが必要なのかということを考えてみましょう。ハイコントラストが有効なケースはおおよそ以下の通りです。
- 主題を強調させたい
- 誰でも見やすくしたい (アクセシビリティ)
どちらもとてもとても重要ですが、今回は2つ目の「誰でも見やすくする」方を少し掘り下げたいと思います。
色覚異常者のためのハイコントラスト
日本では、男性で約5%、女性で約0.2%の割合で色覚異常のある人がいます。 色覚異常にもいろいろ種類がありますが、そのような人を含めた誰でも見やすくするために注意すべきことの1つにコントラストがあります。
Web Content Accessibility Guidelines 2.0 のコントラストの項目によると、 コントラスト比4.5:1以上を意味するレベルAAは最低限満たす必要があり、コントラスト比7.0:1以上を意味するレベルAAAを満たすことがより十分であるとあります。
達成基準 1.4.3 を理解する | WCAG 2.0解説書
まとめ
この記事では、ハイコントラストをテーマに「コントラストとは何か」「ハイコントラストがなぜ必要か」ということを書いてみました。何気ないことが、自分自身には関係ないかもしれないけれど、他の人にとってはとても重要なことだったりします。誰に対しても行き届いたものを作れるエンジニア、デザイナーになりたいですね。
余談
余談ですが、OSやアプリごとにハイコントラストモードが用意されていることも多く、僕はvscodeやiOSをコントラストを高くする設定で使っています。僕は特に色覚異常ということはないのですが、UIが認識しやすいのもありますが、何となく見た目がかっこいいと思うからです笑
なんか凄そうなサーバレスSPAの話
こんにちは! HANDAI JKの杉森です!明けましておめでとうございます!今年もHANDAI JKをよろしくお願いします!予告通り、ブログの定期更新の一発目になります! 今日の内容はサーバレスSPAについてです!
SPAって?
SPAと聞いてもピンとこないと思います。スパがどう関係あるのかと思う人もいるかもしれませんが、ここでは関係ないです笑
SPAとは、シングルページアプリケーション(Single Page Application)の略です。ページ遷移をなくし、単一のページでコンテンツの切り替えを行なっていくWebアプリケーションの構造を指します。SPAを利用しているページで有名なものにGoogleのGoogle マップやfacebookが挙げられます。
SPAのメリット・デメリット
メリットはこういったことが挙げられます。
- ページ遷移によるストレスがない
- 高度な表現ができる
- ネイティブアプリの代用ができる
最近でこそほとんどなくなったと思いますが、ページ遷移が遅くてイライラしたことはないですか? SPAではページ遷移がないので、そういったストレスがなくなります。また、ブラウザの挙動に縛られなくなり、様々なUIが実装できるようになります。こういったことから、ネイティブアプリの代用がWebアプリケーションで実現できます! ブラウザでそれができるというのはすごいメリットですね!
ですが、当然デメリットも存在し、こういったことが挙げられます。
- 初期ローディングにかかる時間が長い
- 古いブラウザでは動作しないこともある
- 実装コストが大幅に増える
- 開発者が少ない
ページ遷移がなくなる分、初期ローディングが長くなる傾向があります。このため、古いブラウザでは処理ができない場合があるというような問題があります。また、ブラウザで任せていた処理を実装しなければならないため、実装コストがかかります。そういったことから開発者が少ないようです。しかし、Vue.jsやReactの登場により、以前より実装は容易になっています!
サーバレスだと何がいいのか
ここ数年、あちこちでクラウドというワードを聞くと思います。SPAは、クラウドと相性がいいと言えます!主にこういった点が挙げられます。
- スケーリングが容易 (ロードバランシングによる一貫性の拡張が必要ない)
- コストが主にリクエスト数次第
- サーバ要らず
主にコスト面でその恩恵を受けます。サーバが必要となる一般的なWebアプリケーションはサーバを動かし続ける必要があるため、その分コストがどうしてもかかります。(ピーク時とそうでないときである程度スケールの調整はできるので、コストは抑えられる) しかし、サーバレス SPAの場合、リクエスト数によって変わるので、ある程度の規模であれば安く済ませられます。また、サーバレスのため、ApatchやNginxといったWebサーバ、アプリケーションサーバの面倒を見なくていいのも大きなメリットとなります!
終わりに
サーバレスSPAについて興味を持っていただけたでしょうか?サーバがあって当たり前と考えていた僕にはとても衝撃的でした! 実際にちょっとしたサイトを作成しているので、完成次第こちらで公開したいと思います!ここまで読んでいただきありがとうございました!
今年のまとめとブログの定期更新について
こんにちは! HANDAI JKの杉森です!今日が今年最後のブログ更新となります!今日を合わせて今年も残り4日間... 今年中にやり残していたことをやりきって、来年も頑張りましょう!
今年のまとめ
少しだけ、今年のHANDAI JKを振り返ってみましょう。4月にはLT大会が行われました!過去最大規模での開催となりました!
あのときはまだ参加者サイドだったなと懐かしく思います! そして、7月にもLT大会を行いました!
参加者・登壇者のみなさま、お忙しい中での参加、本当にありがとうございました!!!
来年について
HANDAI JKの今後についてですが、1つ皆さんに謝らなければならないことがあります!
1~3月はイベントを行いません!
4月以降から新たに始める複数の企画の準備に全力で取り組むためです! LT大会をはじめ、楽しみにしてくださってる皆さんには残念な思いをさせてしまいすみません!!今後ともHANDAI JKをよろしくお願いします!
空いてしまう期間がありますが、何もしないわけではありません!ここ数日、ブログ更新を再開したのもこのためです!
来年から定期ブログ更新を行います!
より多くの人に技術に興味を持っていただくため、HANDAI JKのメンバーが隔週金曜日の13時にブログの新規公開を行います。様々な専門分野を持っているので、楽しみにしていてください!更新予定は以下の通りです。
更新日 | 執筆者 (予定) |
---|---|
1/10(金) | 杉森 |
1/24(金) | 石田 |
2/7(金) | 赤沢 |
2/21(金) | 原口 |
3/6(金) | 杉森 |
3/9(月) | 杉森 |
3/13(金) | ? (新メンバーです!) |
3/20(金) | 赤沢 |
3/27(金) | 石田 |
皆さんに楽しんでいただけると嬉しいです!さらにお知らせがあります!なんと...
4月末にLT大会開催予定です!
今年4月に過去最大規模で行われたLT大会が来年4月に開催予定です!詳細が決まり次第、連絡させていただきます!
最後に
今年1年間ありがとうございました!来年、さらにパワーアップしたHANDAI JKを今後ともよろしくお願いします! 以前のブログから引っ張っていた締めの挨拶がこれでやっと言えますね! それでは皆さん、良いお年を!
ちょっとしたレガシーと戦ってきた(後編)
こんにちは! HANDAI JKの杉森です!もうすぐ今年が終わります!皆さんにとって、どんな年だったでしょうか? 来年に向けての抱負を立て始めるのもいいかもしれませんね!
今回は、「ちょっとしたレガシーと戦ってきた」の後編になります。前回の記事はこちらになります!
問題点の整理
前回の最後に挙げたCSVファイルをデータベースへ移行するための問題点は以下の4つです。
- Excel内でセル内改行が行われていたため、1データが複数行に渡っている
- データとデータ間にあるはずのカンマがたまに存在していない (例の30と31の間)
- 日付入力欄に「不明」という入力がある (型の不一致)
- Excelの表示で分割されていた項目の統一が必要 (後に追加された仕様)
時系列で解決していったものを話していこうと思います。また、説明の短縮のために箇条書きの番号でどの問題を取り扱っているのかを説明します。(社内データを扱っているため、一部記述不足・表記の変更を行なっていますがご了承ください)
問題1のためのSQL文と問題2の出現
セル内改行されたために、ダブルクォーテーションで囲われているという性質をあえて生かしてデータを分けます。複数行にデータがまたがっているということから、一行ごとに分けるのではなく、データの最後にある「",」で分けることにしました。各データ内の分割はカンマで行われているため、SQL文はこうなります。
load data local infile "ファイルのパス" into table テーブル名 fields terminated by ',' enclosed by '",';
そのあと、データベースを覗くとこうなってました。(表示は番号のみで全体の一部)
| 29 | | 30 | | 32 | | 33 | | 34 | | 35 | | 36 | | 37 | | 38 | | 39 | ...
31番がありませんね... こういったデータが複数存在していました。これで問題1については解決になりますが、問題2が顕著に現れました形になります。
仕様変更による問題4の発生と問題3の解決
ちょうどこのあたりで項目の統一が決まり、問題4が発生しました。幸い隣同士で項目が並んでいますが、面倒だなと思いました笑 ここからは問題3の解決になりますが、テーブルの定義で、すでにDate型でカラムを作っていたため、「不明」となっていた文字列はこうなっていました。
+------------+----------+ | 日付 | count(*) | +------------+----------+ | 2016-03-08 | 1 | | 2013-03-15 | 2 | | 2014-12-01 | 2 | | 0000-00-00 | 28 | | 2016-03-11 | 6 | | 2015-11-13 | 1 | | 2015-04-01 | 1 | | 2015-04-10 | 1 | | 2015-09-29 | 1 | | 2012-02-08 | 1 | | 2014-08-12 | 1 | …
0000-00-00となっていました。これは、MySQLの独自仕様であり、NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様です。データベースにある分には問題ないのですが、アプリケーションでこの値を扱うとなると対応していないことが多いです。また、PostgreSQLなどの他のRDBMSには移行しようとする際にエラーとなります。そのため、「不明」に該当するものはNULLとして扱うことに決定し、新たに追加される日程不明のものはNULLとすることになりました。そうなると、0000-00-00は邪魔になるので、データの更新を行います。
update テーブル名 set 日付 = NULL where 日付 = 0000-00-00;
+------------+----------+ | 日付 | count(*) | +------------+----------+ | 2016-03-08 | 1 | | 2013-03-15 | 2 | | 2014-12-01 | 2 | | NULL | 28 | | 2016-03-11 | 6 | | 2015-11-13 | 1 | | 2015-04-01 | 1 | | 2015-04-10 | 1 | | 2015-09-29 | 1 | | 2012-02-08 | 1 | | 2014-08-12 | 1 | …
これで問題3の解決となりました! Date型を扱うが、カラムの設定をNOT NULLにしたい場合は、1000-01-01 をNULLの値として扱うのが良いようです。
問題2と4の解決 (物理)
ここまではそれっぽく解決してきましたが、ここからはCSVファイル自体を修正することとなりました。文字列処理のプログラムの作成も考えましたが、それをするよりもファイル自体に修正を加える方が速いと判断したためです。もっとデータ量が多かったら、コード書いて文字列処理が行われたCSVファイルを作成した方が速かったと思います。
問題4の解決
ここで使用するのがエディタのAtomになります。CSVファイルを覗いていると、統一する項目の間は、いずれも「","」で区切られていました。この規則性があるのならば、一括でその部分を空文字に置換してやればいい! そう考えてAtomを開き、エディタの下の方に出てくる「すべて置換」を使いました。一発ですべて変わるので、置換したくないものが含まれていないか確認しましょう。
問題2の解決
これは劇的な方法も思いつかず、データベースの情報から間の空いてる番号を見つけ出して、その番号のデータの前後を見て、カンマを付け足すという作業でした...
こうして
CSVファイルの修正が完了し、以上のことを行うことで無事に全データが仕様通り、データベース内に移行されました。その後、表示・入力フォーム等の作成・自動バックアップのための設定を行い、無事に社内ツールの一機能として移行が完了しました!
反省と振り返り
今回はエクセルレガシーとの戦いになりましたが、多くの企業が何かしらのレガシーを抱えています。その中で意識しないといけないことは以下の点だと感じました。
- なぜレガシーは生まれたのか
- なぜそのレガシーを変えなければならないのか
- どういった手段が良いのか
- 新たに作ったものがレガシーとなったとき対応しやすいか
変化が激しい業界において、レガシーというものは避けられない存在です。放置しすぎず、適切にメンテナンスをしていくことが大事なことだと思います!
約数時間でこれらを実装しました。それ自体はいいことかもしれませんが、もしこれにバグが混じっていたら、その後に影響を及ぼしてしまうため、反省が必要です。エンジニアとして何かをしていく以上、冷静に、真摯であるべきだと感じました!
ここまで読んでいただきありがとうございました! 今年中にもう一本更新する予定ですので、それも読んでいただけると幸いです!
ちょっとしたレガシーと戦ってきた(前編)
こんにちは! HANDAI JKの杉森です!あっという間に年末ということで、色々忙しくなってくる前に年納めの出来事の話をしようと思います。内容は「ちょっとしたレガシーと戦ってきた」です。
今回は、前編ということで技術向けというより、その前の導入部分になります。 (え、まだブログ更新やってたのかって? いやいや、生きてるしこっからが本番だから(震))
前置きとレガシー
現在、とあるバイト先でWebアプリケーションの開発をしています。そんな中、とある情報について1人の社員に聞きに行っているという光景を何度か目の当たりにしていました。そこで、その社員に話を聞いていくと、こういった内容と要望を聞くことができました。
- 会社の情報を扱っているマクロの使われたExcelファイルがある
- かなり古くて使いにくい
- なんとかしてほしい
何とかして欲しいというすごい投げ方されました... これじゃ状況がよくわからないんで詳しく聞くと、こうなりました。
- 会社の製品情報を扱うマクロの使われたExcelファイルがある
- バックアップは1つデータを増やすごとに手動
- マクロを組んだ担当者はいるが、覚えてない
- 共有しづらい構造になっている
- 検索がしづらく、データが増えてきたから使いにくい
- なんとかしてほしい
ここまで掘り下げればどうすればいいかはかなり見えてきますね。ところで、今回の問題は典型的なエクセルレガシーと呼ばれるもので、企業の業務部門がExcelを使って自ら開発し、利用し続けてきた業務システムなどを指すそうです。ファイル作成日が1997年の1月(まだ生まれてねーわ...)であり、かなり古いものとなっていることがわかります。僕のMacbookでは、マクロが動かなかったのでバージョンの問題も抱えているようです。
社内データベースとツールへの全面移行
以上のような問題点を抱えていたため、次のようなことを行うことにしました。
一度社内データベースにデータを入れてしまえば、それ以降はツールからの管理になるため、扱う製品の増えない年末に行いました。ここから話すのは、一番大変だった社内データベースへの移行です。
CSVファイルをエクスポートしたら
今回使用したものは以下のものです。
ExcelからCSVファイルをエクスポートすることは大したことではありません。問題はそのCSVファイルの中身です。これが一例です。(データは構造はそのままですが、内容は実際のものと異なります)
30,****,OK,OK,した,不明,A,,20XX/X/X,XXXX,XX,4F,"20xx/x/x xxx " ---------------------------------------(業務連絡が並んでる) 20xx/xx/xx xx --------------------------------------- --------------------------------------- --------------------------------------- --------------------------------------- ","20xx/xx/xx xx --------------------------------------- --------------------------------------- -------------------------" 31,******,OK,不明,していない,不明,不明,不明,不明,,不明,XXX,"20xx/x/xx xx -------------------------------------------------- ------------------------", 32, ...
ぱっと見は大したことないことですが、違和感を感じる人は感じると思います。このCSVファイルの問題はこうなります。
- Excel内でセル内改行が行われていたため、1データが複数行に渡っている
- データとデータ間にあるはずのカンマがたまに存在していない (例の30と31の間)
CSVファイルの構造以外の問題はこうなります。
- 日付入力欄に不明という入力がある (型の不一致)
- Excelの表示で分割されていた項目の統一が必要 (後に追加された仕様)
これら4つの問題点が存在しています。これらをCSVファイルの編集とMySQLのコマンドを用いて、解決していきます。この続きは近日中に公開いたします。
ここまでで
次回が解決編となります。他にも色々やったりしてましたが、まだこの手のレガシーが残っていることを思うと、そういうところはまだあるのだなと感じますね。学生エンジニア(笑)がどう解決したか見ていただけるとありがたいです。今年中にアップするんで、まだ良いお年をとは言いませんよ! ここまで読んでいただきありがとうございました!
LT大会の中で交流会をやります。
こんにちは、HANDAI JKの原口です。今回の記事は次回イベントについての追加情報です。
交流会をやります!!!
今回のイベントでは、LTのコーナーの他に参加者間の交流会を予定しています。
前回は希望者だけイベント終了後に自由に交流してもらっていたのですが、 今回はテーマとグループ形式をきちんと揃えて、誰でも話しやすいコーナーにしようと考えています。
僕も知らない人しかいないイベントに行って交流コーナーがある時、 コミュ障 + すでに盛り上がってるグループへの混ざりずらさで中々話せないことがあるんですけど、 その心配は必要ないです。
授業や実験・サークルなどの学校生活の話から、技術の話、進路の話まで、何か得れること間違いなし!!!
先輩に聞きたいことがあるとか、技術系の知り合いを阪大内で作りたい学生の参加をお待ちしています!
参加申し込みの方はこちらのgoogleフォームから、登壇希望の方はこちらのgoogleフォームに入力をお願いします!(登壇される方は参加申し込みのフォームへの記入は不要です)
皆さんの参加お待ちしています!