「コンポーネント」を含む日記 RSS

はてなキーワード: コンポーネントとは

2019-08-07

単一責任原則vsカプセル化

投稿につき至らない点があるかもしれないが容赦してほしい。が、指摘は受け入れる所存。

俺はとあるUIコンポーネントライブラリ開発者だが、先日議論されたあるコンポーネント設計について悩み続けている。

これを読んでくれた人の設計センス知識経験から第三者の率直な意見を聞きたい。

悩んでいることの概要は、

ざっくり言えばこの2択だ。

どちらも間違った考えだとは思えないので、そもそもどちらかの捉え方がおかしいのだと思う。そういった意見も聞きたいが、まずは読んでみてほしい。

設計対象コンポーネントは、よくある触って動かせるスライダーである。下記リンク先のようなものだ。

https://material-ui.com/components/slider/

前提として、このコンポーネント構成要素を下記とする。

加えて、下記も前提としてほしい。

Sliderというコンポーネントクラスを作るとして、これらの構成要素をライブラリ-ユーザー間でどう分担するかという点で、AさんとBさんで意見割れた。

それぞれの意見を要約すると下のようになる。Aさんはカプセル化を狙い、Bさんは単一責任原則を重視している。

Aさんの構成イメージは下記のような感じ

画面
└ Slider         (ユーザー作成)
   ├ 背景バーノブ
   └ 進捗バー

Aさん案の場合だと、Sliderクラス内部で勝手にそれぞれの要素を作成し、自分の子にするなりして表示する。

Bさんの構成イメージは下記のような感じ

画面
├ 背景バー     (ユーザー作成)
├ ノブ         (ユーザー作成)
├ 進捗バー     (ユーザー作成)
└ Slider       (ユーザー作成)
   ├ 背景バーへの参照    (ユーザー指定)
   ├ ノブへの参照        (ユーザー指定)
   └ 進捗バーへの参照    (ユーザー指定)

Bさん案では、ユーザー構成要素それぞれを作成し、Sliderにそれを食わせる。

SliderはAさん案のように各構成要素を構築する必要はなく、ノブの移動や進捗バーサイズ変更だけすれば良い。

Aさんはユーザー制御する必要のない背景バーノブ、進捗バー構成隠蔽(カプセル化)しようと提案したが、

Aさん案に対しBさんは、単一責任原則観点から「各構成要素の構築や表示」という責任を外すべきだと訴え、Bさん案を提示した。

またBさんは、コンポーネントユーザーが扱うべきものであり、コンポーネントコンポーネントを内部で勝手使用しているのは混乱を招くとの見方もしている。

ただしAさんの考えの通り、実際に各要素の構成ユーザー制御するユースケース存在しない。

その場では「単一責任原則」を持ち出したBさん案で決定された。

しかしなんとなくAさん案派だった俺はモヤモヤしたまま家に帰り、本当に単一責任原則に反しているのか、カプセル化よりも大事なのかと悩み続けている。

ここまでが事実となる。

さて本当にBさんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・

第三者による意見が聞きたい。周りのコメントに左右されない率直な意見が望ましい。なんとなくな意見も歓迎する。

満たすべき機能は見た目だけではないがそこは置いておいてほしい。

以下は個人的意見とか思ったことや疑問など。

2019-07-07

クソ過ぎだったもの改善されていくと気分がいい

昭和生まれなのだが、昔は本当にクソだったなあとつくづく思う。

映像端子

コンポジット、S、D、コンポーネント、D-subDVIなどがあったが

今やHDMIとDisllayPortまでほぼ絞られてきている。音声端子も一緒になったのがいいところだ。

一本線を繋げばすぐ綺麗に映像が映る。

が、ノートPCプロジェクター類がいまだD-subを搭載していたりするのが許せない。いい加減切れ。

  

②壁電源コンセント

もうほとんど見なくなったが黄色い壁コンセントを知っている人はいるだろうか。

あれがもうガタガタ動くようになっているくらいの古い物が残っていた時期は

さっさと工事しろと思ったものだが、世の中からほぼ消えたので喜ばしい限りだ。

  

白熱電球

LEDに変わったのでいらなくなった。うっかり触るとあっちぃってなったあのクソなものだ。

虫はLED以上に集まってくるしで本当に糞だった。

  

ブラウン管テレビ

画質が悪い。今見ればどれだけクソな画質なのかがよく分かる。

ぼやけた色しか出せないインテリアとしてしか有効性が無い。こんなものはもう今の時代不要

  

⑤窓ガラス

昔の窓ガラスは本当にすぐに結露するクソ仕様だった。断熱性も悪く、クソクソクソ。

今の時代の窓ガラスは断熱性が段違いだ。いい時代になった。

2019-07-03

役に立たないReactJS vs Vue.js

Reactはライフサイクルを細かく設定でき、その辺きちんと設定できないとまともに動かない。一方Vue.もライフサイクルを細かく設定できるが、適当に書いてもなんとなく動く感じがある。書き方はReactのほうが好きで、フックを使って疎結合コンポーネントを作れるのは大きい。

あとReactはVirtualDOMからTypeScript恩恵を受けやすそうな気がする。VueTypeScriptは試してないけど、DOM内のv-なんちゃらattributeのSyntaxチェック働かなさそうだし。

2019-07-01

linuxwindowsコンポーネントになる日が来るとは

10年前には考えもしなかったな

2019-06-02

5年ぶりに機種変してiPhone Xsにしたんだが

ちなもともと使ってたの5Sね。

深刻に困ってなかったってのもあるけど、我ながら良くもったね、いやそれはいいいい。

それよりも、画面でっかくなって困るのが、結構おおくのアプリサイトUIパーツが右上や左上にある事。

コンポーネントが右上に集約してるとかじゃなくて、下にあったり、右上にあったりする。

もう、片手操作についてはデザインサイドも投げてるのかもしれないけど、ちっちゃいウザさとしては、操作のために視線をいちいちさまよわせて「戻るボタン」とかを探さなくちゃ行けない。

おおむね良いことが多い機種変だけど、アプリサイトがついていってない感じがスゴくする。

2019-06-01

anond:20190601015822

ロードバイクに乗り始めて5年になる俺が断言する。

自転車買うならば、迷うことなく、その時に買える最高のものを買え。

30万~40万の値段のミドルグレードで、電動化対応フレームのものと、装備品を揃える位がお前の経済感覚だと丁度いい。

自転車にハマってしまうと、より速く、より遠くへ、より高い山を走りたくなる。

特にロードバイクと共に旅をする輪行にはまると、1日に200㎞位は走るようになる。

想像してみてくれ、夏に北海道信号一つない大平原に伸びた一本道を、風を全身に浴びながらまっすぐ走るのを。

日本アルプスの峠道の頂上を目指して登って、頂上から見下ろす絶景を。

しまなみ街道の海沿いの道を潮風浴びながら走るのを。

休憩がてらジェラートを食べたり、夜は美味しいものを食って、温泉に入って、疲れた体をマッサージしてもらったりしてな。

間内でわいわい言いながらの旅は本当に楽しくて、沖縄佐渡島、果ては台湾フランスイタリアと色んな所へロードバイクを持って旅したくなる。

色んな所へ行って、自分自身エンジンにして走るのは、めっちゃ気持ちいいけど、自分の体力には限界ってもんがあるから機材を良くしたくなってくる。

そうすると1㎏でも軽いロードバイクが欲しくなるし、0.1㎏でも軽いホイール、電動コンポーネントが欲しくなる。

そうなってから自分が買ったのが、拡張性のない入門用の安価で重たいロードバイクだと、2台目を買う羽目になるんだよ。

ハマれば、誰もがそうなる。120%そうなる。

初めに無理してでもいいのを買っておけば、パーツのアップデートだけで済むし、その分だけ旅行が楽しめるんだよ。

夏冬に快適に走れるウェアとか、もっと体力付けたいと室内トレーニング器具が欲しいとか

無限に湧いてくる物欲で、あっという間に100万位溶かすことになるから最初20万とかどうということないぞ。

始める気になって、一緒に走れる仲間がいるなら、いいのを買え。気づいたら年に数千キロ走ってるって事になるんだから全然損した気にならんってw

ミニベロはやめとか、あれじゃ距離は走れないし、他の友達と一緒に走るのが大変になると思うからな。

2019-05-22

4000Stepを超えるVueコンポーネントを見た

もはやどこまでが methodでどこからがcomputedなのかも判断できなかった。

VuexのModuleも5000Stepを超えていた。管理しているstateの数は100近かった。

もちろんTypeScriptなどという高尚なものを使っているわけもなく。コメントからなんとなくObjectの型を推測してデバッグするしかなかった。

テストなんてあるわけない

chromeデバッグツールけが頼りだ。Vueデバック用の拡張機能は重すぎて動かなかった。

非同期処理のハンドリングも雑だった。

async関数の中で平気でコールバック関数を呼んでたりするし、

awaitがついていないことも多々あった。

アプリ挙動が安定しないのは明らかに雑な非同期処理のせいだったが、コードが巨大すぎて原因を突き止めるには至らなかった。

処理の途中でObjectの型が変わることもしょっちゅうだった。

さすがJavaScriptだ。必要になったら必要になった分だけいくらでもプロパティを追加できる。

でもごめんなさい。追加してくれたのはありがたいけど、僕には今目の前にあるObjectに何が入っているのかもはやわからないんだ。

君が好意で追加してくれたプロパティを、僕は活かすことができない。

このコードにらめっこを始めてから3日間、全く進捗はなかった。

今日やっとなんとなく全体像がつかめてきたところだ。

明日からは、何かしらの進捗が出せるかもしれない。

とりあえずModuleを分割するところから始めようか

いや、その前にテストを書く必要があるのかもしれない。

でもどうやって書けばよいのだろう。正解がわからないんじゃテストの書きようがないじゃないか

週末には、上司に何かしらの報告を入れなければいけない。

どう説明すればよいだろう。いっそさじを投げてしまおうか

「あまりにも難解すぎて私には無理です」

と。

でもたった3日で諦めてしまってよいのだろうか?

しかしたら、これはものすごい成長のチャンスなのかもしれない

僕が世間知らずなだけで、世の中にはこんなコードがいっぱいあって、みんなこの試練をくぐり抜けて一人前になっているのかもしれない。

たかだか4Kステップときでガタガタ言うなと言われてしまうかもしれない。

この程度でさじを投げていたら、なんの仕事もできないのかも・・・

とりあえず今日疲れた。もう寝てしまおう。

明日になったらなにかいアイデアが出てくるかもしれないし

しかしたら親切な増田たちが、あっと驚く素敵な解決方法を見つけてくれるかもしれない。



明日自分に幸あれ

2019/5/22 記

2019-02-25

ボードゲームカフェ経営が困難な理由

都市部だけではなく地方都市でも、ボードゲームカフェないしはスペースが増えており、業界の盛り上がりを感じるが、他方、廃業余儀なくされた店舗もある。この業態が難しい理由について、とりわけ地方においての理由も列挙する。

都市部地方共通

・回転率が悪い。

テーブルの回転率(1日の客数÷席数)は重要経営指標であり、カフェな4、5回転は欲しいが、短くて数時間、長くて営業時間いっぱいは在席されるので、席あたりの回転率は良くて1、2程度。であれば、客単価は普通カフェの少なくとも三倍程度は必要か。

飲食ボードゲームの相性が悪い

食べながらゲームするのは、難しいしコンポーネントが汚れる。同テーブル提供できるのは、せいぜい軽食ドリンクのみ。

・軽ゲー主体余儀なくされる

重ゲーは回転率を悪化させ、また、インスト時間を取られるため、繁盛店になれば、軽ゲー主体となるのは余儀なくされるが、ライト主体となり、固定客が付きづらい。

地方部に顕著】

・平日日中集客が困難

学生や平日休み社会人地方には少ない。

車社会

基本、地方民は車で移動するため、郊外立地なら広い駐車場必要なり、それなりの賃料が地方でも必要となる。

オープン会、自宅会との競合

十分なスペースと駐車場を備えた公民館などが格安で容易に借りらことができ、オープン会が盛んである。また、自宅でも比較的スペースがあり、個人宅でのクローズ会も盛んである

2019-02-20

オンラインエロゲ終了でオフラインプレイヤーを書いたら感動した

「対魔忍アサギ 決戦アリーナ」というオンラインゲーム(エロゲ)が終了する

まあ終了自体は仕方ない。このゲームゲームと言うには余りに大きな設計ミスを抱えすぎており、また、システム的にもかなり古くなっている。

だいぶ前からオンラインゲーム終了時にどうするか、という話はあるけど、あまり進展はない(ソシャゲ、ネトゲ等のサービス終了後のゲームの保存について考える、とか、米国でサービス終了オンラインゲームを著作権法例外とする動き―ESAは反対とか)。一つ根本的な問題として、本当にオンライン重要ゲームオフラインモードに余り意味がないのも大きい。

でも、対象エロゲ特に抜きゲ)なら話は別

何せ、最低限エロシーンだけ再生出来れば需要を満たす。

逆に、ゲームとしてのサービスが終わろうが俺には見たいエロシーンがあるんだよ!

anond:20190209083051 とかでも書かれていたけど、エロの質はいいし、ここにしかないものも多い。しかもそれは(ゲーム上で)自分が苦労して手に入れたものだ。勝手に閉じてほしくない。

……けど、運営コストを考えたらそうも言ってられないのはよく分かる。

というわけで、今こそオフラインプレイヤーの出番だ。

自分入手した分のデータダウンロードして、後は各人がローカルPC再生すればいい。

必要機能は大きく分けて、サーバからデータダウンロードしてくる部分、それからデータカードエロシーン)を閲覧するパートだ。

ちなみにこのゲームは初期に作られただけあって(?)、エロシーンに機能が少なく、BGV はおろか BGM も無い。オーバレイも1枚のみで、基本的に背景(シーン画像含む)と、テキストに 1:1 対応するボイスしかない。

これなら割とできそうな気がしたので保存・再生するソフトウェアを書いてみることにした。

というわけで出来たものこち

https://aakeeper.appspot.com 驚くほどあっさりできてしまった。

でも、今はできた物自体の話はいい。それより作る過程で色々感動したのでその話をしたい。

今や OSS には巨人の肩どころか常にジェット機に乗ってるくらいのツールが揃っている

今回使ったのはざっくり以下のもの

これらのツールに関して、自分殆ど学者だ。

Quasar FrameworkNode.js も Electron も使うのははじめて、他はちょっと触ったことあるけどそんな詳しくない。 ES もあまり好きでなかったので基本的には避けてきた。

にもかかわらず、全体で余暇時間2週間分くらいで出来た。

Quasar Framework は、とにかく物凄くよく出来ていてびっくりした。今回 Electron モードしか使っていないけど、本来はこれで SPA/PWA/モバイル(Cordova) アプリケーションが作れるという凄まじい対応幅のプラットフォームになっている。着手時に 1.0beta の予告だけあるというタイミングの悪さ(数日後に出た)だったので、 0.17 系を使った。しかし、それでも十分すぎるほどよく出来ている。

ES は今でも嫌いな点は多いんだけど、今回 async/await を使って感動した。これは素晴らしい。他の言語にも欲しい。

CoffeeScript趣味だけど、とにかく短く書ける点が素晴らしい。あれは終わったという人もいるが、記述量の少なさは js 系では他の追従を一切許していない。今回みたいな急いでいるケースでは、括弧の世話を焼いたり eslint おばさんと語り合う時間はない。CoffeeScript ならコンパイラが全部上手くやってくれる。

HTML5 ベースGUI は今や chronium の各種アクセラレーションのおかげで、並のポータブル GUI ツールキットよりずっと高速に動作する。

また、Vue.js + pug は非常に記述量が小さくて目的の画面がすぐ作れ、カプセル化がしやすコンポーネント再利用も容易だ。

Babel/Webpack は正にバッドノウハウを煮詰めて固めた感じだが、こいつがバッドな部分を吸収してくれるおかげで開発者正気を保てる。ただし追求しだすとSAN値が減る。

ユーザから見ると、Electron 製のアプリメモリをやたら喰う、少しもっさりしている、配布バイナリが巨大になるという問題は確かにある。

しかし、そうだとしても何より、とてつもなく高速に作れて、各種プラットフォームで割とちゃんと動く。

自分は色々初めてだったので結局2週間分くらい掛かったけど、前提知識が揃っている人なら本当に数日でできたりするんじゃなかろうか。

状況は良くなっている

つい数年前まで、クロスプラットフォームアプリケーション作成というのは本当に本当に大仕事だった。こんなに早く手軽に書ける事は無かったし、ユーザ側でもラインタイムインストール必要とか環境側のハードルも非常に高かった。

自分は今まで知らなかったけど、最早そういう時代は終わっていた。

もちろん過去に数多くのクロスプラットフォームフレームワークが登場しては消えていったのと同じく、Electron もいつかその仲間入りをするだろう。

でも確実に、びっくりするくらい状況は良くなっている。

興味があるけどまだ触ってないという人は、ぜひ試して感動を味わってもらいたい。

Happy Hacking!

2019-02-06

[]シマニョーロ

自転車コンポーネントの二大メーカーシマノカンパニョーロコンポを両方組み合わせて作られた自転車コンポセット。両社の性能のいいとこ取りを目指す。

変速機ブレーキカンパニョーロホイールだけシマノというような簡単にできる組み合わせからディレイラーシマノでシフターはカンパニョーロという調整作業が難しそうな組み合わせまで様々なバリエーションがある。全部一社で揃えるより金がかかることもしばしばらしい。

シマニョーロを愛用する人はシマニョーラと呼ばれる。

綴りは shimagnolo または shimanolo

2018-11-27

ドキュメント重視は悪か

旧態依然とした企業批判するときに、よく大企業正社員ドキュメント作ってばっかで実装しない等々の批判が書かれて、そんな時間あるなら手を動かしてモノを作れとよく言われるけど、そんなにドキュメントって悪かな?

きちんとしたドキュメントを作って、後工程品質担保するってフロー大事じゃない?こないだバズったJAXA教授もそんなこと言ってなかったっけ?ドキュメンテーションによって全体の意思統一しないと、個別最適化された謎のコンポーネントで溢れかえっちゃわない?

みんなが褒め称える、日本が誇る製造業の大半はこういう仕事の進め方をしてると思うんだけどな。なぜかIT業界だけはこういう仕事の進め方を叩かれる気がしてならない。

2018-10-17

ケイ新卒の出してくるAPI設計がクソすぎる

自分フロントエンドエンジニアなんだが

ケイ新卒サーバーサイドエンジニアのお客さんが作ってくれるAPI仕様がクソすぎて辛い。

お前さ、UIとかちょっとは考えたことある?ていうか画面デザイン資料みてくれたよね?っていうレスポンスなんだ。

例えば画像が並んでいるようなコンポーネントがあったとする。で、画像の種類がAとBの2タイプあるとき

[{
 type: A,
  image: {
   source: https://~~
 },
},
{
 type:B,
  source:{
   original: {
    Horizontal: https://~~
  },
}]

っていうのを平気でだしてくる。いやそうじゃなくてどうせpタグとimgタグに入れんだから同じ形式でほしいんだが。ていうかHorizontalってなに。

しかしなぜだか伝わらない。なぜだ。

しかも「自分デザインについては本をたくさん読んでいるし学校でも習って知ってますから」といってUIの話を全く聞いてくれない。

SPAときAPI設計もクソで、注文の内容を送って受理されたら進行のステータスが変わるのだが

「内容送って成功したら、次のステータスフロント計算してパラメータで入れて別のAPI叩いてください。内容受け取るやつとステータス変えるのと2つ作っとくんで」

みたいなのが出てくる。電話口でいやそうじゃなくて、、、といっても聞いてもらえない

一番腹が立ったのは、エラーときはどうなりますか?と聞いたら

「あ〜、たしかに〜それは全く考えてないですw」と言われた時。なんとかしてくれ。

今日「ま〜〇〇社の〇夫さんは通信のこと全然わかってないみたいなんでwwwフロントエンドエンジニアとはとても呼べたもんじゃないですね〜ww」と上司にいっているのを聞いてしまった。

ペコペコしてる中小企業おっさんだと思ってバカにしてるんだろうか。なんか自分おかしいのか?

2018-09-10

anond:20180909073549

組込み界では今時のプログラミング界隈の常識の多くが通用しない。最初あなた相手にするのはRAM 1kB, ROM 4kB、クロック 20MHzなどというMCUである

使用する言語はC99かアセンブラである。幸か不幸かC++を使わされることもある。既にC++で書かれたプロダクトに係わってはならない。

当然フロントエンド界隈などのようなイミュータブルインスタンスを大量に使い捨て富豪的言語アプローチ採用は難しいだろう。

トラブルが起きたときプログラムだけでなく回路図を読んでハード側に問題があるこを示せないと極めて立場が悪くなる。

しろプログラムし易いコンポーネント選択や回路構成積極的に口を出していかないと動かない責任けがソフト担当者に投げられて割を食う。

開発環境Windows上のEclipseベース統合環境が使えれば上等であり、運が悪ければMCUメーカーお仕着せのクソIDEを使わせられる。Mac優雅に開発することはまずあり得ないだろう。

底辺企業バージョンコントロールシステムの導入のための意識改革簡単ではない。もし強行に導入しようとすればあなた孤立する。

誰かがIoTだ、機械学習だの言い始めても社全体として主力製品を作るのでなければ本気で取り組んではいけない。あなたがそのテクノロジー理解していても誰もサポートメンテもしてくれないのだから

2018-04-13

このコンポーネントが関わるんだったらレビューを依頼してくれないと困る、確定の人が出てくるの(しかも向こうは善意だと思っている)、個人的そいつ自分ボトルネックであると名乗り出ただけではレベルだるいし、そいつ過労死直前であろうと知るかよって感じだ

そこそこ勉強する人たちの集団の中でそれをやるということは、自分と同じことができるにはどれくらいやればいいかとか考えず、人に教えてこなかった証左なので

2018-04-11

Vue.js日本語ドキュメントについて

バージョン1.xの頃からVue.js使用している。

ドキュメント英語で読んでいる。

しかし、英語ドキュメント意味不明のことが多々ある。

英語ドキュメント英語おかしいのだ。

そういう時は日本語ドキュメントを読む。作者とやりとりしたりして、不明点が解決している可能性があるからだ。

しかし、その日本語さら意味不明なのだ

OSSドキュメント基本的に有志がボランティアでやっていることは承知している。

でも、英語が苦手なんだったら、翻訳作業に関わってはいけない。

試しに、適当なページを見てみる

https://jp.vuejs.org/v2/guide/single-file-components.html

「多くの Vue プロジェクトでは、グローバルコンポーネントは、new Vue({ el: '#container '}) の後に各ページの body においてコンテナ要素をターゲットにすることに続いて、Vue.component を使用して定義されています。」

どういうことだろう?

原文はこうだ。

「In many Vue projects, global components will be defined using Vue.component, followed by new Vue({ el: '#container' }) to target a container element in the body of every page.」

まりグローバルコンポーネントは「new Vue({ el: '#container '}) 」の後で「Vue.component」を使って定義されることが多いと言っている。「to target a container element in the body of every page.」は意味不明だが、ここはこういう定義の仕方をする目的をさしていると思う。

次の文章もよくわからない

「これは view拡張するだけに利用された小さな中規模プロジェクトにおいてはとても有効です。 あなたフロントエンドJavaScript 全体を操作するようなもっと複雑なプロジェクトでは、これらの点において不利益になることは明白です。」

「小さな中規模プロジェクト」「あなたフロントエンド」とはなんだろう、書いた段階でおかしいと思わないのだろうか。機械翻訳をするなら、日本語ドキュメントを用意しておく意味はない。

原文はこうだ

「This can work very well for small to medium-sized projects, where JavaScript is only used to enhance certain views. In more complex projects however, or when your frontend is entirely driven by JavaScript, these disadvantages become apparent:」

JavaScript特定の表示の拡張だけに使用されるような小規模〜中規模のプロジェクトにおいて、この方法はとても有効です。しかし、もっと複雑なプロジェクトや、フロントエンド全体をJavaScript制御する場合、この方法では次のような問題があります。」

ForkしてPull Requestするのもだるい

こういうのが大量にあるから

2017-11-13

anond:20171113191656

基本的にはデザイナーと組んでしか仕事してないから、必要そうなコンポーネントを洗い出して、デザイナーがそれに合わせてcsshtmlを作って静的なデザイン確認サイトをつくる。

その間に先行してある程度適当htmlを組んでおいて、合体させる。

大体の場合デザイナーのほうが先に仕事があがるので、合体作業サポートしつつデザイナーさんにお願いする。

ぜんぶ一人でやる場合はよくわかんないや。

2017-10-21

むやみに抽象化?するのやめてほしい

え、半日で変更差分が 3 行と 5 行と 20行程度しかないんだけど・・・ じゃないんだよ!

あれこれ調べて試して最終的にそれだけの変更ですんだんだよ!!


引き継ぎもなく会社辞めた人が作ってたシステムコードを渡されてこの修正依頼対応してね、とか言われても作りが意味不明

有名ドコのフレームワークライブラリならともかく、見るからにその人自作らしいもので作られてる

愚直にイベントに対して、あれやってこれやってそれする、って書いてたり、変な上書きはせず UI コンポーネントプロパティ変えればそのまま反映されるようなら簡単に直せそうだったのに、

複雑に継承を重ねたコントロールクラスちょっと見た目変えるだけでも一苦労

値を変えても反映されずに親クラスで変な制御ついてたりするし、現状のものフィットさせすぎてちょっと操作性変えるだけでも大規模に変更が必要そうに見えるし、どこから手を付ければいいのかって状態だし

どこで値が変えられてるとかが追うのだけで時間が過ぎていく

どこがどういう仕組になってるとか、こういう変更ではここを変えればいいとかいう手引きがあればまだましだが、そういうのは全くない

余計なことせず単純にコントロール並べて、単純にデータ取得や保存する作りで作られていたなら1日もあればで終わったであろう簡単修正依頼が1日で1割程度しか終わらない

作った本人はこの方が楽だったんだろうが、他の人が使えないもの作るのはやめてほしい

というか、ファイル名が連番でどのファイルがどの画面に対応してるからすら開いてみないとわからないレベルだったのだが作った本人はこれで苦労しなかったのだろうか・・・

仕様書対応表があったのかもしれないが今あるのはこのコードだけだ


最後まで面倒見れないなら、世間一般の作りに合わせるとか有名どころのライブラリ情報があるものを利用してほしい

退職のつもりなくても、病気とか怪我で代わりの人に任せるとかはあるだろうから出来る限り、独自の作りはやめてほしい

有名どころのOSS並に丁寧なドキュメントFAQとか作れるなら別にいいけど

2017-09-06

最近リア充の間でボードゲーム流行っているようで、

元々ボートゲームが好きだった自分の家に遊びに行っていい?と言われたので遊びに来てもらった

んでもってうちに来て重いコンポーネントゲームを見て「うわきも」って言うのな

ほんとなんなんだよこいつら

2017-07-25

やっぱ大手SIerって馬鹿だわ

大手SIer下請けベンダーに出向してる。

HTMLCSSjQueryでシコシコモックアップを作る。

百歩譲ってこれはまだいい(コンポーネント志向皆無とか後々Smarty移植することをまったく考えてないとか言いたいことはいっぱいあるが)。

その後、レビューにあたって説明資料なるものを作る。

Excelキャプチャを貼り付けて動作記載するのだが……。

なんで動くものが目の前にあるのにわざわざ文字に起こすんだよ。

動いているの見ればいいだろうがよ。

更新するボタンを押したら何が起こるのかわからいから動きを書け?

ボタンを押下したら対象データ更新する」

それでいいのかよ! 見ればわかるだろうがよ!

ちなみにこの後、この説明資料を基に画面設計書を作成する。

そしてまたレビューを行う。

この工程が分かれている理由不明

やっぱ大手SIerって馬鹿だわ。

2017-05-15

Microsoft の Fluent Design System って

既存のUWPのUI周りにいくつか新しいコンポーネント足してリネームしただけっぽいんだけど、違うかな?

最近MSによくある「ドキュメントがいろいろ用意されてるのになんか分かりづらい」っていう典型な気がする。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-05-22

「Reactは大規模SPA用途以外はコスパ悪い」っていう先入観意味不明

しろweb制作入門用に最適だと思う。

個人的な考えは以下の通り。


UI構造がおおよそのコード構造と一致する

そもそもコンポーネント指向ライブラリからチュートリアルからして構造化を基本において書かれてるのが入門用にこそ適していると思う。

だって初心者の頃jQueryで場当たり的にコード追加していって九龍城みたいになったこと、あるでしょ?

もちろん自分で間違いを犯してその痛みを知るってのも方法論としてはありかもしれんけど、

DOM操作抽象化したライブラリから入って、徐々に具体的なところに落とし込んでいくのが効率的じゃない?


しろ小規模案件にこそ導入して「構造化とコード再利用」を意識づける

ライブラリ自体構造化を念頭に置いてるから自然とパーツごとに作るようになって、

その次の段階として自分の作ったパーツの再利用を考えられると思う。

jQueryで場当たり的に(以下略


抽象化の高いレイヤーから入って抽象化の低いレイヤー学習範囲を伸ばすべき

jQueryってホントに何でも出来るからキチンと扱える技術を既に持ってる人には良いだろうけど

やっぱ初心者には逆に指針がぶれやすいと思うんだよね。

チュートリアル書く人にもそれぞれ別の方法論があって、

しかもその振れ幅が広くて、どの方法論もそれなりに意味がある場合が多い。

正解が沢山ある問題をいきなり解かせるんじゃなくて、

まずは答えがある程度決まってる問題から入って、徐々に馴らしていくべき。


jQueryWebフロントエンド界隈のアセンブラだと思う

最初に手を出すには抽象化の度合いが低すぎるというか、

ある程度経験を積んだプログラマーこそが手を出すべきと言うか。

だってアセンブラ機械語がなくなってないのと同じように

webからDOMの直接操作不要になることもないと思う。

どんなに抽象化が高度になっても、裏でやってるのはDOMの直接操作なんだから

でも、大事な基礎技術からといって、それだけで済ませて技術革新放棄するべきではないでしょ

しろ抽象化の高いところから入門して、基礎技術に触れる必要が出来てから触った方が理解が早いと思う。


から初心者や小規模案件にこそReactを!

と、私は考えます

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん