IT 関連のややこしい用語
IT 関連の用語は使い所によっていろんな意味をもってややこしい。ざっと思いついたものを挙げる。
フロントエンド
- Web アプリケーションにおける、ブラウザに動作させる実装。 HTML/CSS/JavaScript など。 クライアントサイド。「フロントエンドエンジニア」と言った場合はこれを指す。
- 機能をユーザーが触れるようにするもの。これ自体が Web アプリケーションを指す場合もある。アプリケーションA (バッチ) が処理結果をDBに保存し、アプリケーションB (Web) がその情報を画面に出力する、といった場合は「アプリケーションBはアプリケーションAのフロントエンド」と呼んだりする。
アプリ
- スマホアプリ。スマートフォンで動作するアプリケーション。
- PC アプリ。 Windows なら .exe、 Mac なら .app など。
- アプリケーション。 Web アプリケーションなど。 1. および 2. を含む。
特に口頭で「アプリ」と言った場合はなぜか 1. を指すことが多い。携帯電話→ケータイ、みたいな。
リポジトリ
- Git などバージョン管理システムのホスト先。Git であれば GitHub など。
- npm などパッケージマネージャのホスト先。
- Repository Pattern の実装。
サービス
- ユーザーが認識する単位の Web サービス。
- 機能単位のサービス。マイクロサービス、SAOなど。
- Windows サービス。
Atom
Unity
- 3D に強いゲーム開発エンジン。 https://unity3d.com/
- DI コンテナ。 https://github.com/unitycontainer/unity
いずれも C# 関係なのが余計にややこしい。
エンジニア
GAS で Google カレンダーの1日の空き時間を取得する
最近予定が詰まっているのでスキマ時間がどれくらいあるのか取得したくなった。ので GAS で書いた。
function myFunction() { const calendar = CalendarApp.getCalendarById('hogehogei@example.com'); const date = new Date(); const freeTime = getFreeTimeMinutes(calendar, new Date()); // あとは気分に応じて Slack に投げたりする } function getFreeTimeMinutes(calendar, date){ const events = calendar.getEventsForDay(date); // 終了時間の昇順にした後に開始時間の昇順にする const sortedEvents = events.sort(function(a, b) { return a.getEndTime() - b.getEndTime(); }).sort(function(a, b) { return a.getStartTime() - b.getStartTime(); }); // 時間がかぶっている予定をひとまとめに `block` とする const blocks = []; var block = { start: sortedEvents[0].getStartTime(), end: sortedEvents[0].getEndTime() }; sortedEvents.forEach(function(event) { const start = event.getStartTime(); const end = event.getEndTime(); if(block.end < start){ blocks.push({ start: block.start, end: block.end }); block.start = start; block.end = end; } if(block.end < end){ block.end = end; } }); blocks.push({ start: block.start, end: block.end }); // 9:30 - 18:00 を定時とする const bizStart = new Date(date.getYear(), date.getMonth(), date.getDate(), 9, 30, 0); const bizEnd = new Date(date.getYear(), date.getMonth(), date.getDate(), 18, 00, 0); // 完全に業務時間外の予定を省く const filteredBlocks = blocks.filter(function(block) { return bizStart < block.end && block.start < bizEnd }); // 業務時間から溢れた分をカットする const cutOffBlocks = filteredBlocks.map(function(block){ if(block.start < bizStart) block.start = bizStart; if(bizEnd < block.end) block.end = bizEnd; return block; }); // 業務時間内で重複を取り除いた予定の合計時間 var sumMinutes = 0; cutOffBlocks.forEach(function(block) { sumMinutes += (block.end.getTime() - block.start.getTime()) / (1000 * 60); }); const bizMinutes = (bizEnd.getTime() - bizStart.getTime()) / (1000 * 60); return bizMinutes - sumMinutes; }
業務時間外を省いているのは、飲み会とかの予定も入ってるから。 休憩時間とかフレックスは未対応です。
もっと効率よく書ける気はしている。
Function App リクエストサイズの上限
Function App に HTTP で Post するときのサイズ上限は web.config でデフォルト値が指定されている。 v1.x では 100MB だそうだ。
azure-functions-host/Web.config at v1.x · Azure/azure-functions-host · GitHub
でも v2.x では指定されてない。
既定値だと 4MB だけど、この値がそのまま使われるんだろうか??(未検証)
HttpRuntimeSection.MaxRequestLength Property (System.Web.Configuration) | Microsoft Docs
Table Storage は Count できないよ
タイトルのとおりで Table Storage は件数を取得するための API が無い。愚直に全件取得するしかない。
せめてレスポンスを軽くするための手段として、 PartitionKey
だけを Select するという手段がある。
var query = new TableQuery<DynamicTableEntity>() .Select(new string[] { "PartitionKey" }); var count = table.ExecuteQuery(query).Results.Count;
ただし単発のクエリは最大1000件までしか返ってこないので、セグメント化する必要がある。
var count = 0; var query = new TableQuery<DynamicTableEntity>() .Select(new string[] { "PartitionKey" }); TableContinuationToken token = null; do { var queryResult = table.ExecuteQuerySegmented(query, token); count += queryResult.Results.Count; token = queryResult.ContinuationToken; } while (token != null);
しょっちゅう Count するべきものじゃないんだろうな。
ひとり振り返り
毎週金曜日の夕方に、ひとりで1週間を振り返っています。
手順
- その週にあった出来事をA4用紙にひたすら書く。
- それぞれ、良かった / イマイチだった、あるいは追加で思うことがあればマインドマップ的に追記していく。
- イマイチだったことに対して「この情報が足りないから調べてみよう」など
- 良かったことは Keep とする。そのほか、次の週あるいは将来的にやりたいことを Try とする。
- 具体的なアクションがあれば個人のタスク管理ツールに転機する。
マインドフルネスでいうジャーナリングというエクササイズに影響を受けています。
紙に書く理由は、気分が振り返りモードに切り替わってる気がするのと、矢印を生やしやすいからです。
タスク管理ツールは、いまは Trello を使っていますが todoist でも紙のふせんでもなんでも良いでしょう。
書く順序は思いついた順。KPTのように良かったことから、というアプローチは特に考えません。良かったことからが効果的なのは、チームでの発言が促進されるからですが、ひとりでやる分にはその観点を考慮する必要はないでしょう。
効果
- 「頭の片隅にある、なんか気になってるたこと」がたくさんあると個人的にしんどいので、洗い出してタスク管理ツールにまかせられる。脳をデフラグする感覚に近いです。
- やってる感。
改善したいこと
- Try がどんどん溜まっていく。。長期的な Planning もどこかでやったほうが良いかもしれない。
Ionic でカスタムコンポーネント
最近 Ionic を触ってハマったのでメモ。
目的 コンポーネント hoge
をページ fuga
から呼び出す。つまり、 fuga.html
に以下のように記述できるようにする。
<hoge></hoge>
はじめます。コマンドからコンポーネントを作成する。
$ ionic g ? What would you like to generate: component ? What should the name be? hoge
/components/components.modules.ts
に、作成したコンポーネントへの参照が追加される。なので呼び出し側からはこいつを参照すればよい。
呼び出し側のページを fuga
とすると、 fuga.module.ts
から下のように参照する。
import { NgModule } from '@angular/core'; import { IonicPageModule } from 'ionic-angular'; import { FugaPage } from './fuga'; import { ComponentsModule } from '../../components/components.module'; // 追加 @NgModule({ declarations: [ FugaPage, ], imports: [ ComponentsModule, // 追加 IonicPageModule.forChild(FugaPage), ], })
これでも hoge
が見つからない旨のエラーが出る時がある。 fuga
をモジュールとして扱えていない。app.module.ts
で
import { Fuga } from '../pages/fuga/fuga'
を
import { FugaModule } from '../pages/fuga/fuga.module'
とする。さらに、同じく app.module.ts
で declarations
や entryComponents
などに入っていたらこれらから削除し、 imports
に移動する。
晴れて、 fuga
から呼び出せる。
<hoge></hoge>
参考: