  |
はてなキーワード: Jsonとは
photoshopで作ったpsdのwebデザインを渡されて、フロントエンド担当がHTML/CSSコーディングしてるんだけどどうなのこれ？
そういう職場もある
客に見せるデザインカンプの方が先に必要なことも多々あるのでは
最近はFigmaのようなWebページやモバイルアプリなどのUIデザインのツールが多くある
それをそのPhotoshopのようなデザインカンプ作成に使うのはありだと思う
というか、こっちの方がデータがXMLやJSON形式だったりするので、デザインからそのままコードに落とし込みやすい
Figmaでネイティブのデスクトップアプリさえデザインして一発で落とし込む試みをGitHubで開発している人もいる
上述したとおり、デザインカンプのことですね
いきなりHTML/CSSを書くと、後から抜本的な調整が不可能になる
プログラミングも同じで、かなり書いてから、やっぱあれナシだから、みたいなのは嫌なので
それをなんか知らないけど、普段使わねーphotoshop開いてルーラー出して、
自分も馬鹿げていると思うこともあるが、そもそも社内研修やスクールでそう教えてるところもある
自分もそう教えられたときがあって、その場では嫌々ながら教えられたやり方で課題をこなしたりしてた
ここで逆らっても意味ないなあ、と思ったので
客なり講師なりを全否定するなら、そこに自分がいる意味がなくなっちゃうよなあ、とも思ったので
正直、そういう場合はちょっと揉めることが多いのだけど、仕方がないですね
仕様等の客の話を聞きながら勝手に自分の中で、あのライブラリやあのフレームワーク使えば楽勝だろう、と思っていると、
後々になってその前提としていたライブラリやフレームワークでは実現が難しい仕様を喋りだしたりすることもある
今の会社含めて2社しか経験してないので、一般的かどうかは判断できないが、前職ではHTML/CSSまでデザイナーの人が書いてたぞ
そういう職場もある
Zeplinは知らないけど、ツールにクソコードを吐かれるのはよくあるので、そこは相談するしかないのかなあ
相談するだけ無駄なケースも多いので、転職するとか、仕事自体を蹴ってしまうことも考えるべきかも
現に生きてけないで🍣
本来はこうでしょ？
（中略）
今になって思い返しても、自分のやり方の方が正しかったんじゃん、やっぱアホだろあれは、
と思うこともあるけど、世の中そんなもんなのでなんとも言い難い
決定権が自分にないと当然無理だし、フリーランスで決定権が持てても今度は仕事が小さくなるし
それは偏見
例えば、音声のスペクトル、声門とかを画像編集ソフトでプレビュー、加工することもなくはない
もっとも、それ専用のアプリ使った方がいいのは言うまでもないが
自分は普段はPhotoshopを使ってないけど、PSはJavaScriptなどでプラグインが書けるはずだし、
といっても、何でもPhotoshop同様、何でもExcelの世界で、Excelで仕様書とかあんたバカァ？とは思う
（中略）
これもやんわり、なんとかなりませんか？みたいに言うぐらいしかできない気がする
でも、意見するだけで攻撃的になる人もいるので、転職案件なのかもなあ
そもそも何でもかんでもwebページをポスターみたいに着飾るんじゃねーよ
ランディングページならともかく、よく使うwebアプリを着飾るんじゃねーよ、開発もしにくい、使いにくいしでまったく良いこと無い
それは客が要求するのもあるんで
大抵Craigslist, Hacker News くらいのデザインで十分なんだよ
フロントエンドエンジニアみたいな肩書でドヤってる人を見るとウンザリする
いっそJavaScriptなくした方がいいんじゃないかとさえ思うときがある
Webブラウザのタブごとに動作しているわけで、ブラウザが重くなる原因の1つだと思うし、
ブラウザ上でしか動作しないJavaScript書いて人生を消費したくない
でも、本当に？
カラーリングで、開発環境でコードが見やすくなる。マークアップ言語には、markdown, html, wikiなどがあげられると思う。
また、xml, jsonなどのデータもマークアップ言語と言ってよいだろう。
（pythonを使えば否が応でもスペース４つを空けることになるだろう。（あるいはtab一つ分））
まずは、ブラインドタッチでマークアップ言語を書き、一文字でも違うとコンピューターは、こちらの意図通りには動いてくれないという悲しみにひたらないかぎり、
全角スペース、半角スペースを目grep出来るようにならないと、プログミングは上達しないことをここに宣言したい☆
適当にJSONファイルを書くと、勝手にデフォルトのJSONスキーマが出来上がるし、
それをカスタムするもよし、そのまま使うもよし、
バリデーションするときにそのJSONスキーマを指定するだけで済むんだから、
楽っちゃ楽でしょ。
むかしXMLが流行った頃にXMLスキーマだとかWSDLとか使ってたんだけど、まぁ端的に言ってゴミ
これらを使えばXMLがvalidであることを保証できる。たしかにそうだ。
でも仕様とかややこしい割には、バグが減るとか工数が減るとかそういったことの恩恵はまるでありません
誰がこの複雑な仕様を使える？チームの中でもちゃんと理解できてるのが一人入れば良いほうだろう。
JSONスキーマも似たような運命をたどるとしか思えないので、手を出す気にならない。
JSONは単純な構文で、適当に書いて適当に入出力使って、インターフェースとなるデータ構造は、API利用者同士で密に相談しあって使えばいいんじゃないかな。それで何事もスムーズに行くはず。
一般公開とかするなら仕様を自然言語で文書として残しとけばOKで、そこらへんをプログラムで取り扱いたいってのは、まぁ理想としてはわかるんだけど、うまくいくとは思えないんだよね。
自分みたいに低能作業員には難しいけど、優秀な技術者を取り揃えてるところなら実装、運用できるのかなぁ…
スキーマ出てくるとこれをプログラム的に取り扱って、データやり取りするためのインターフェース部分を自動生成しましょ、みたいなくっそ寒いノリがでてきて、
この自動生成された部分がだいたいバグってたり、仮にバグってなくてもバグを探すために、自動生成されたきっしょいコードを延々と人間の手で解析するみたいな、非人道的な作業が発生するんだよなぁ
仕事で使わされそうになったらやだな
DjangoとかRailsとかって、プログラムのいろはを知っている人でも理解するのに苦労するような独特な構文が多い
あくまでフレームワークで面倒な部分は省いているから仕方ないんだけど。
デコレータが何なのか継承が何なのかとかわかっていてもその意味を読み解くのに一苦労する。
ましてやRailsから勉強しよう！なんて人にとったら「なんかわからんけど動いた」という人が大半になるんじゃないかと思う。
Railsから入った人はたぶんRailsのためだけのやり方しか習得できんし、応用が利かないレベルになっちゃうんじゃないかと思う。
ORMを使わずに純粋にJavaなりでバックエンド書いてDB設計したりとかリクエストが来たらJSONを返すアプリケーションサイドを作ったりってなんとなく経験した人がRailsなりDjangoなりやるとこういうことか、これは便利だ、でもここは融通が利かなくてつかいにくいなみたいなことがわかるんだろうけど
それは先週金曜日のことだった。
慌ててCOCOAを起動して確認するも、「陽性者との接触は確認されませんでした」との表示が。
新型コロナウィルス流行後、いわゆる三密に相当する施設は避けてきた。
買い物に行くときも、自家用車を利用してきた。新型コロナに感染するような覚えは全くない。
さっきの通知は何だったんだ？そういえば、COCOAはバグがいろいろ残っているというし…
急いでCOCOAの不具合について調べると、似たような現象に直面している人はいるらしい。
どうやら、携帯の設定項目をたどると、接触ログを記録したjsonファイルが書き出せるので、
そのログの中を検索し、Match Countという項目が0以外になっている箇所があれば濃厚接触があったという事らしい。
…残念ながらMatch Count :1となっている箇所を発見。陽性者と濃厚接触している。
それからが大変だ。
厚生労働省のCOCOAに関するQ & A の問23に、上記のような不具合が起きたら問い合わせしてほしいとの記載があったので、
状況を記載して、証拠となるjsonファイルを添付した確認メールを送付。
職場の規定でCOCOAに反応があった人は2週間の出社停止なので、すぐに会社に連絡を入れる。
同時に、陽性者との濃厚接触した日付がわからないので14日以内に会った人に注意喚起の連絡。
14日以内に会った人でCOCOAを入れていた人には、バグの存在とjsonファイルから確認する方法も説明。
今回はたまたま14日以内に会った人が全員職場関係のエンジニアだったので難なく説明できたが、
はあ、疲れた。感染拡大防止のためとはいえ、アプリのバグのせいで無駄な仕事が増える。
正常系のテストもまともにできていないであろうCOCOA開発元に対して若干の怒りを覚える。
さすがにこの完成度の低さはないだろうとネットで情報を収集していると、ずさんな開発体制(物理的に無理のあるリリース日程や、2つ動いていた開発プロジェクトの1本化など)であることが判明。
ちなみに、この不具合は今日現在の最新バージョン1.12でも改善されていないし、改善予定のアナウンスもない。
今時スマホゲームですら、ちょっとした不具合(例えば、アイテムの効果が正しく設定されていなかった等)に対しての修正予定を公開しているのに、
下手すりゃ人命にかかわるアプリがバグ自体を公にせず、修正予定も公開していないことに苛立ちを覚える。
そして日曜日。確認の問い合わせを送っていた厚生労働省から返信。
メールの内容の転載はやめてくれとの記載があったので、転記は控えるが、要旨を書くと
「ポップアップが出たのにアプリで接触履歴が確認できない場合はiOSまたはAndroidの設定から接触チェックの項目を確認してください」とのコピペのような文章。
まあ、サポートも問い合わせ殺到しているだろうし、返信遅れるのは仕方ないなと思っていたが、
きっちりログファイルまで送って濃厚接触していると思われるのだがどうでしょうかと聞いてこの返答はあまりにも人を馬鹿にしてるなと思った。
多分、急にサポートに人手が必要になったので、バイトをかき集めて適当に回していると思われる。
それにしてもだ、そんな適当な回答をするなら初めからQ & Aに設定から接触チェックを確認して1以上なら接触しているとの前提で行動してくださいと書けばよいだろうに。
ちなみに、8/19日12時現在でも厚生労働省のQ & Aは下記のままであり問い合わせるようにとの文言になっている。
問23 陽性者との接触があったようなプッシュ通知が表示されましたが、接触確認アプリを開いて陽性者との接触を確認すると「陽性者との接触は確認されませんでした」と表示されます。どちらが正しいですか。
Android搭載のスマホをご利用の方は、問２１、問２２をご確認ください。これらで解決しない場合、またはiOSをご利用の場合は、大変お手数ですが、メール（appsupport@cov19.mhlw.go.jp）にてご連絡いただきますよう、お願いいたします。
さて、話はアプリの完成度が低くてストレスがたまったという話だけで終わらない。
私が周囲に反応したという事を報告したせいで、思わぬ影響が出たのだ。
職場の同僚が、私の濃厚接触者だったという事でコロナマン扱いされて出社するのは軽率だと怒られ問題になるという事件が起きたのだ。
アプリのバグのせいで私が陽性者と接触した日がわからないため(正常に反応するケースでは接触日がわかるとのこと)、
最大2週間のマージンを取って、その間にあった人全員に連絡をしたのだが、
彼自体は私が陽性者と濃厚接触する前に私と合っただけかもしれない。
それならば完全に風評被害だ。ちなみに私も私の濃厚接触者も全員体調に問題は起きていない。
話は長くなったが、このアプリにいろいろ思うことはある。
まず、陽性登録者が200人程度の時点で反応したという事でコロナの影は意外に身近にあると感じられたこと。
これで全陽性者が登録していたらえらいことになっているだろう。
次に、このアプリが反応した時の社会の対応指針が現状ではうまく設定されていないこと。
現状では反応が出ただけの人間のその接触者までもがコロナ陽性者と同じ扱いを受けて、社会的に行動制限を課されてしまう。
アプリを活用するための合理的な指針が社会に浸透することを望む。
そもそもBluetoothの電波強度で濃厚接触を判定しているため、近くにいても濃厚接触にならないケースがあるだろうし、
十分距離を取っていても濃厚接触とカウントされる恐れがある。(携帯のBluetoothモジュールのアンテナ次第で当然電波強度の指向性出るよな?)
また、アプリで反応が確認できないというのは論外だし、確認できても次のステップにつながらない。
例えば、LINEアンケートでたまに送られるようなアンケートが自動的に配信され、怪しい兆候があれば医療機関のデータベースに登録され、優先的に取り次げる等の工夫がほしい。
私自身はなんだかんだで感染拡大防止しないと社会も経済も正常に戻せない思っているタイプなのでできる限りの協力はしたいのだが、アプリの完成度の低さには正直あきれ返っている。
最近は真面目に感染拡大防止をする人間を「コロナ脳」とかいって揶揄する人がTwitterをはじめとするネット上に増えた印象を受ける。
GoToキャンペーンなんかもそうだけど、正直者が馬鹿を見る社会システムがこうした問題を拡大させているように思う。
自分がプログラムを書き始めた数十年前の自分ならこういうデータとして扱うのが超面倒くさいコードを平気で書いたかもしれないけれど、今は一瞥してそれで渡されても取り扱えるけれど、自分だったらそうは設計しないなとは思う。
そもそも、連想配列/辞書を作ってJSON読み書きはライブラリーにやらせるからJSONの設計がーという発想もそんなにない。
本当に迷惑なんだ。
センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。
センスのない奴は、普通の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。
普通の人なら、何も考えず以下のような実装をするだろう。フィールドの定義とデータが分かれているのは、ユースケースによってフィールドが可変だからだ。
[
{fieldName: "id", title: "id", type: "number"},
{fieldName: "name", title: "商品名", type: "text"},
{fieldName: "price", title: "値段", type: "number"}
]
[
{id: 1, name: "商品A", price: 100},
{id: 2, name: "商品B", price: 200},
{id: 3, name: "商品C", price: 300}
]
ところが、センスのない奴はたとえば以下みたいな意味不明な実装をナチュラルに行う。
[
{id: "0-0", val: "商品名", type: "text"},{id: "0-1", val: "値段", type: "text"},
{id: "1-0", val: "商品A", type: "text"},{id: "1-1", val: "100", type: "number"},
{id: "2-0", val: "商品B", type: "text"},{id: "2-1", val: "200", type: "number"},
{id: "3-0", val: "商品C", type: "text"},{id: "3-1", val: "300", type: "number"}
]
一応言っておくと、これは実例の一部を分かりやすいように切り取っただけであり、本物はもっとひどい。
センスのない奴っていうのは、スキル云々の問題ではなく、そもそも認識している世界が常人と異なるから、矯正は無理だし、チームにいると非常に迷惑なんだ。だから、プログラマにはならないでくれ。