nDiki : 仕様

仕様 - specification

2015年7月3日 (金)

浴室の照明をパルックボール D60形に変更

浴室のランプが昨晩切れたのでヨドバシ・ドット・コムで注文。もともとついていた「NEC コスモボール D形 15形 60W相当タイプ E26口金 EFD15EL/12」というのはもうないようなので、「パルックボール D60形 E26口金 電球色 EFD15EL12EF」にした。当日に届くのはとても助かる。

 NEC コスモボール D形 15形 60W相当タイプ E26口金 EFD15EL/12
 12W
 全光束 890lm
 9000時間

 パルックボール D60形 E26口金 電球色 EFD15EL12EF
 12W
 全光束 810lm
 8000時間

仕様上はちょっと暗いみたいだけれど特に気にならない。

そういえば9000時間もつとすると1日8時間(浴室なのでもちろんそんなに使わない)使っても3年使えるはずなんだけどね。


[ 製品レポート ]

スポンサード リンク
[ 7月3日全て ]

2015年11月30日 (月)

「なぜ Excel 方眼仕様書だと駄目なのですか?」

先週ワークフロー改善内容についてレビューしたところ添付されていた仕様書フォーマットサンプルが Excel 方眼紙だったので、これを機会に止めましょうとお願いしておきました。 そうしたところ今日になってツッコミをいれた人と同じグループの別の人から「なぜ Excel 方眼仕様書だと駄目なのですか?」と質問されました。即答するとなんか適当なことを言ってしまいそうなのであとで回答しますねと答えておきました。

Excel 方眼仕様書をもらった時の嫌だなという感情は「ファイルでの管理だから」「Excel だから」「方眼スプレッドシートだから」など複数の混ざり合った理由からやってきます。

この中で「ファイルでの管理だから」「Excel だから」は環境によっては排除できない場合もあるし、ユースケースにあっている場合もあるので単純に良い悪いとはいえません。

しかしながら「方眼スプレッドシート」で書かれた仕様書というのはいつでも不便なので止めて欲しいです。書かれている文章の部分が論理的な入力になっていないのが一番嫌な点です。1文毎に別のセルに書くとか、字下げは次の列のセルからとか、箇条書き項目ごとに次の行のセルとか。仕様レビュー仕様変更での更新が非常にやりにくい。説明を書き足しにくい。

だからといってシート毎に大きな図形を貼ってその中にテキストを書けば良いといったものでもありません。それこそ方眼にする理由はないでしょう。

編集を阻む仕様書は、仕様の品質を上げるコストを高くするのです。

[ 11月30日全て ]

2016年6月4日 (土)

初アイカツスターズ!

予定していた歩く会が流れたので今日はアイカツスターズ!になってからの初アイカツ!活動日になりました。

光沢感のあるホログラム仕様のカードにオンデマンド印刷されるアイカツ!カードはなかなか綺麗。少しカールした状態で出てくるのはいかにもな感じはします。あとは裏面がオンデマンド印刷ではないのでそこは以前とくらべてちょっと寂しい感じ。ドレスメイクを選ぶとマイキャラの名前やプレイ日が印刷されるのはへぇーと思いました。

筐体としては、タッチパネルになったので各選択画面での操作が直感的になったところが良いです。音量設定のせいだけなのかスピーカーの向きのせいなのか、今日のお店では音が聞こえにくかったのはちょっと残念。

マイキャラの「ねんれい」入力画面で、右下に「30より上」というボタンがあって「あっ……」てなりました。

[ 6月4日全て ]

2016年9月30日 (金)

インターンシップがんばったぞい!

「がんばるぞい!」という意気込みで9月1日から配属されたインターンの方が就労型インターンシップの最終日を迎えました。1カ月間お疲れさまでした。

今までで一番幅広くトライ

私のいるチームでインターンに来ていただくようになって4年目ですが、今年は一番幅広く様々な業務に取り組んでもらうことになりました。「仕様決め」「デザイン担当と調整」「マークアップコードの依頼と受け取り」「実装」「コードレビューアとのやりとり」「QA 項目の作成と依頼」「ユーザーサポートへのリリース共有」「リリース」と、様々な担当の人とやりとりしながらリリースしていただいたのは今年が初めてです。体調不良をかかえつつ大変だったかと思いますがやり遂げられました。素晴らしいです。実際のサービス開発の1つのケースとして良い経験となったならチームとしても嬉しいです。

思い出

  • 2日目に迷子。
  • 6日目に救急。
  • 5回一緒にランチだったけれど結局同席だったのは2回。

Blog を書くまでがインターンシップ

今回いろいろ経験したことについて、ぜひふりかえって1カ月間で感じたこと・思ったことをまとめていただければと思います。頭の中で考えるだけではなく手を動かして書き出すことで自分の中での理解を深められるでしょう。

Blog を書くまでがインターンシップです!

[ 9月30日全て ]

2016年11月7日 (月)

テキストファイル todo.txt でのタスク管理

先週の金曜日からテキストファイル todo.txt でタスク管理をするアプリを試してみています。

1行に1タスクを書くシンプルな todo.txt フォーマットが定義されており、それら対応した Todo.txt CLI やスマートフォン向けアプリ、デスクトップアプリ、エディタプラグインなどがいろいろ作られています。

これらを使ってタスクを追加・編集していきます。もちろんテキストエディタで簡単に追加・編集できます。Dropbox を使うことで複数のデバイスでも問題なく運用できます。

アプリ

まずは以下のアプリは使うことにしました。

  • Mac
    • TodoTxtMac
      • 複数のファイルをそれぞれ別ウインドウで開けます。
      • 残念ながら日本語入力と相性が悪く、実質テキスト入力はできません。
      • インクリメンタル検索で絞り込みができるけれど AND 検索はできない模様。
  • EmacsiA Writer・Atom
    • ファイルに変更があるとすぐに再読み込みしてくれるので、他のアプリとの併用に便利。
  • Android
    • Simpletask
      • UI はシンプルですが使い勝手は良いです。同時に1つしかファイルは開けません。
  • iOS
    • SwiftoDo
    • Simpletask ほどではないけれどまずまず使えそう。

サブタスク

仕様上サブタスクという概念はありません。「+プロジェクト名」という記法でタスクをタグ付けできるのですが、これだけだと見にくいので

 # プロジェクト名 h:1
 (A) タスク1 +project1 @office
 (B) タスク2 +project1 @home

のように書いてみています。「h:数字」は hidden を表す key:value で、各アプリはこれが書かれたタスク(行)を隠すことができます。一方 Markdown 対応テキストエディタで見出し扱いにしてくれるので視認性が良くなります。

雑感

コンテキスト(@文字列)やプロジェクト(+文字列)をタスク文中に埋め込める点、そしてそれらが空白は許さないことから WikiForum に書き込んでいるような感じがしました。

いわゆる開始日指定にあたる threshold や繰り返しのための rec などが指定できるため一通りのことはできそうです。 Remember The Milk から一部タスクを移して運用してみます。

[ 11月7日全て ]

2017年1月1日 (日)

nDiki ソースファイルの拡張子を txt に

この nDiki の記事ファイルはテキストファイルなのですが、ファイル名拡張子を dkd/dkk にしていたのでテキストアプリでファイル一覧にでなかったり DropboxGoogle ドライブでプレビューできなかったりするなど不便でした。

なのでこの機会に nDiki (の日記システムである DiKicker)の仕様を変えて拡張子 txt でもよいように修正しました。あわせて1万以上ある記事ファイル名を修正。これで他のノート日記系ファイルと同じように Dropbox 以下に移動 & Google ドライブに同期するようになりました。

パーソナルナレッジベースとしてのテキストファイル集約がこれでほぼ完了。

Ulyssesノート日記が一括検索できるようになって個人的にかなり便利になりました。テキストファイル最高。

[ 1月1日全て ]

2017年7月13日 (木)

不具合報告で期待する動作をどう書きどう読むか

不具合報告を BTS 上で起票してもらった時に「報告者の思う期待する動作」が「プロダクトの期待する動作」ではないことも当然あるわけであります。

なので対応する側が、チケットに書かれた「期待する動作」を鵜呑みにしないで判断する必要があります。

不具合報告のハードルを上げすぎないため「プロダクトの期待する動作」の完全理解を求めるものではありませんが、不具合報告する側も「仕様として期待する動作」と「こうだと思う期待する動作」「報告者個人の希望として期待する動作」を混同しないよう意識すべきです。

[ 7月13日全て ]

2017年7月19日 (水)

Perl の Date::Calc::Mktime() の 2038年問題(仕様)

Perl で書かれているシステムで未来の年を使うと不具合が起きるという報告をもらいました。 perl 5.12.0 で Perl コアの時刻関係の関数は2038年問題クリア済みとなっているし、どこでひっかかっているのかなとコードを追ったら Date::Calc::Mktime() が out of range を返していました。

Date::Calc 6.4 のドキュメントにこのことは明記されているしきちんと入力値チェックもされているので、ライブラリ的には問題無く仕様ですね。

対応方法はこれから検討です。

今日のさえずり: ビラ配りの人がビラを差し出す時に「サッ、プルプルッ」

2017年07月19日

  • 08:02 How many files(0-15)?
  • 13:33 Google Domains 気になる。次移管しようかな。
  • 18:59 Date::Calc::Mktime() は 2038-01-19 03:14:07 までしか対応してなかった(仕様)。
  • 20:24 ビラ配りの人がビラを差し出す時に「サッ、プルプルッ」てやっちゃうのなんでだろ。
  • 24:37 Google KeepAndroid アプリについにメモの編集中の「元に戻す」と「やり直し」が入った。数世代のさかのぼれる程度の簡易なもので良いので版管理も入ってくれると嬉しいな。
[ 7月19日全て ]

2017年9月29日 (金)

初全ツイート履歴ダウンロード

自分の Tweet は API で取ってきておおむね nDiki の記事にまとめてあるのですが、使い始めの頃はそんなことをしていなかったので手元にデータとして取ってありませんでした。公式機能で全ツイート履歴ダウンロードができるのは知っていましたがそのうちと思いつつずっとやり忘れていたので、ようやく腰を上げて全ツイート履歴リクエストを設定からしてみたところ、ほどなくして準備完了のメールが届きました。

ダウンロードした ZIP ファイルの中をみると、予想していた通り人間用に HTML ファイルがありました。そしてそれ以外に CSV 形式ファイル・JSON 形式ファイルが含まれていてきちんと利用しやすい形になっていて良くできているなと感心してしまいました。良いですね。

きちんと README.txt をみてみたら HTML ファイル (index.html) は JSON 形式ファイルを読んで表示するページになってました。なるほど。API のレスポンス仕様と同じ JSON 形式をエクスポートデータにしているのですね。

[ 9月29日全て ]

2017年10月20日 (金)

「いい腕時計してくださいよ」と言われてカシオ F-91W-1JF

rimage:/nDiki/2017/10/20/2017-10-20-080202-nDiki-800x1200.jpg

高級そうな腕時計をしている出席者をミーティングでみかけたチームメンバが「Naney さんもいい腕時計をしてくださいよ」と話しかけてきました。むむむ。これは「マネージャーになったらこんな腕時計をすることができるんだぜ」と見せつけてやるしかない。

昨日会社帰りにビックカメラによって有名ブランドの時計を買うことにしました。ファッション性も重視してここはカシオのデジタルで。ファンも多い F-91W をチョイス。

966円(内税)なのに、なにこれスゴイ。スマートフォンみたいにボタンを押さなくても時刻がわかっちゃいます。暗いところでも表示がわかるように緑のライトを点灯させることもできます。そしてなにより電池寿命が7年! 昨今のスマートウォッチのようにこまめに充電する必要がありません。最高。

仕様では「平均月差±30秒以内」ですが、その辺の電波時計をみながら「C → C → C → A で 近い00秒にアジャスト → C」でサクッと調整できます(メモ)。

あと個人的に良いと思っているのがウレタン素材の樹脂バンド。留め具もプラスチックなので他の物を傷つけにくい。腕時計をしなくなった大きな理由の1つに「ノート PC のパームレストにかちゃかちゃ金属ベルトが当たること」があるのでこれは嬉しいところです。

これでチームメンバに将来のマネージャー像のイメージをもってもらうという役割を1つ果たすことができました。めでたし。

しかし若い人やファッションセンスのある人がきちんと身につけるとオシャレなんでしょうけれど、「昭和懐かし」気分で70年代生まれが腕にしているとただ単に貧乏くさい感じになってしまう危険性はかなりあります。

俗称である「チープカシオ」という名前をそのまま陳列棚に表示していたビックカメラさん好きです。


[ 製品レポート ]

[ 10月20日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.105521s / load averages: 0.31, 0.48, 0.52
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker