「インターフェイス」を含む日記 RSS

はてなキーワード: インターフェイスとは

2020-03-29

こんなWebディレクターはいやだ

当方Web系のデザイナー。今やってる案件地獄なので吐き出させてくれ。

初めて仕事をした相手なのだが、デザイナー上がりのようで、自分デザインするときルールに沿っていないことがストレスな模様。

やって欲しいならこちらはオペレーターに撤するのでもいいから、最初にそう言ってくれ。

自分理解していない相手との仕事は面倒が多い。

2020-03-05

いい加減イライラする

なんで新人の俺にアプリ設計がどうなってるか聞いてくんだよ

しかソース見りゃ秒でわかる簡単な内容なのに

双方向依存にならないようにインターフェイスかませて依存性逆転させてるだけだぞ???

聞く時間あればわかることだろ

2020-02-21

USBメモリに保存したデータが一度化けたときがあって、それ以来急に信じられなくなり、ちょっとだけ高いけどMLCUSBメモリのものを使うようにしてみました。今も併用しているTLCやQLCでもバイナリチェックもして差異はないか問題ないと思うのですが、万が一念には念をと用心のためです。

以前はPhotoshopは保存中は他の作業が出来なかったんですが、急にどこかのバージョン(完全にマルチドキュメントインターフェイス(MDI)だった頃らへんを最後境に変にMDIじゃなくなった頃、何言ってるんだって感じですが)で保存しながらでも別の画像を処理できるようになって、

色々やってたら化けたので、ちょっとそういうの用心してます。でもPSD意外は化けたことないので、案外他は大丈夫なのかも知れません。

そんなことがあるとメモリ耐久性とかSSDを使ってると急に不安になってきますSSDに付いてたユーティリティでは残り寿命予測表示されたりして、おまえいつか死んでしまうかー!?ってまた不安が煽られます

今日もいくつか増田を書きましたが、そんな不安に煽られてる場合でないぐらいブクマトラバがつきませんでした。

明日もあるので今日はもう帰ります

また明日よろしくお願いします。

2020-02-05

お父さんの影響でApple製品を使い続けている

おじいちゃんの遺言でApple製品は使わない – NorthPage

私は90年代後半からMacを使いはじめたニワカなので、

とりあえずiMac登場前夜くらいから話をする。

90年代後半に私は中学生だった。

父親Apple信者だったのでお下がりPerforma 588を使っていた。

当時からMac系の雑誌では「MacOSはもうダメだ」と言われていたと思う。

OSとしては完全に進化が停滞していて、

記事で指摘されている「マルチタスクができない」なども悩みの種だった。

システムWindowsが良いがGUIMacが素晴らしい」というのが大方のApple信者認識だった。

もちろん対外的には「すべての面でMacは優れている」と主張するのが当然だったが。

次期MacOSではそれらの欠点がすべて解消され、夢のようなOSになると言われていたが、

その開発に失敗したことApple社への不満は頂点に達した。

https://ja.wikipedia.org/wiki/Copland

正確には、私がMacを使いはじめたのはコープランド開発中止のあとなので、リアルタイム感想は分からない。

しか雑誌などでは「コープランド成功していればこうなるはずだった」というようなことがたびたび書かれ、

まるで理想国家建設に失敗して「どうしてこうなった」と嘆く共産主義者のようだったことは覚えている。

もちろん対外的には「MacWinに負けてない」と主張するのが当然だったが。

Macディレクトリでなくフォルダから素晴らしい」というのはよく分からない。

もっと昔はそういう言説もあったのかもしれない。

言い訳をすると、マカーの言う「直感的な操作」というのは、

たとえば「マニュアルを見なくてもドラッグドロップ意味が分かる」みたいなことではなく、

「このファイルをここにドラッグドロップすればこうなりそう」という直感が当たる、といったような話だった。

まり操作方法一貫性がある」ということだ。

このあたりは現在iOSなどにも引き継がれているところだと思う。

まあ、どの企業GUIデザインに気を遣うようになって相対的な優位性は無くなっているが…。

ジョブズは…個人的にはあまり良い印象がなかった。

自分にとってジョブズは「教祖」というよりは「過激派司祭」だった。

Windows攻撃するぶんには頼りになるが、彼の言うことを何でも信じていたわけではなかった。

MacWinPCの性能比較には無理があったし、過去に言っていたことをすぐにひっくり返すし。

もちろん対外的には「ジョブズは素晴らしい」と主張するのが当然だったが。

とりあえずジョブズが復帰して、iMacが発売されて、Appleは勢いを得た。

ジョブズもなかなか上手くやっているじゃないか

そんなところで「MacOSX」が発表された。

堅牢マルチタスク一新されたインターフェイス

もう雑誌特集を夢中で読んだね。

同時期のWindows2000の画面と比べてみてくださいよ。

https://pc.watch.impress.co.jp/docs/article/990628/desktop.jpg

https://pc.watch.impress.co.jp/docs/article/20001018/wpe05_04.jpg

完全に未来でしょ。美しすぎるでしょ。これは調子乗っちゃうでしょ。

マカーが「MacWindowsより美しい」と言いはじめたのはMacOSX以降じゃないかと思う。

それまでは「Mac可愛い」とか「人間味がある」「愛嬌がある」といった評価が多かったのでは。

話の落とし所がわからなくなってきた。

自分がなぜApple製品を使っているのかを考えると「最初に使ったから」という刷り込みが大きいのだが、

もう一つとして「Apple信者から」というのがあるように思う。

Apple製品は良くも悪くもユーザーに使い方を押し付けるようなところがある。

Appleの御託宣を受け入れるほど使いやすくなる。

Apple信仰するほど離れられなくなるのだ。

これに関してはひとつ思い出がある。

初代iMacの「ホッケーパックマウス」は非常に酷評されていた。

いわく「小さすぎる」。いわく「上下が分からない」。

しかし当時のAppleは「そもそも持ち方が違うのだ」と主張していた。

それまで(というか現在でも多いと思うが)マウスは「手のひらで包むように持つ」のが普通だった。

しかホッケーパックマウスは「指で摘まむように持つ」ようにデザインされていた。

手首ではなく指を動かして操作するから腱鞘炎になりにくいのだ。

私はちゃんと摘まむように使っていたので、ホッケーパックマウスはコンパクトで使いやすいとさえ思っていた。

みんな、どうしてAppleの言うとおりにしないのだろうかと不思議だった。

こういったところがApple宗教たる所以なのだろう。

信じる者は救われるのだ。

2019-12-10

外野から視点

今回の対応は残念に感じる。

オタク向け市場に身をおきながら、初期ロットというオタクが惹かれる1要素を蔑ろにしてるように感じてしまう。

かにランニングコストがかかると思うので、この手のサービスクローズは致し方ないと思う。

とはいえ、交換しますで納得行くユーザーは多いのか?多いなら良いのだけど。

それなりに高いものを夢をもって買ってるだろうから、手放したく無いのがオタク心には思うので、交換対応しなければ文鎮化だとな。

それはユーザー選択です。とか、所持者少ないから影響は少ない。という経営思想費用対効果考えてありだとも感じる。

けど何か根本的なユーザー対応もやもやを感じる。※ リリース延期発表が遅れるなど含めて

せめて、『今』のミクさんが新ハードでも利用できるは後付でよいからうたってほしい。

もしくはシェルノサージュ的な対応はでにきなかったのか?最悪APIインターフェイスだけ公開して、エンドポイント変更できるようなアプデでも良い気がする。

2019-11-24

Apogeeオーディオインターフェイス通して、Ne prayerでSpotifyハイレゾ再生させるより、BT接続したB&O M5の方が音質が良い...

2019-10-22

anond:20191022123119

キーボードマウスGUIも車の運転機構ヒューマンインターフェイスとして完成されきっとるんや

アイデアは色々あったけどみんなポシャったんやで

2019-09-12

「まともなXXXを作れないのか」って言い出すクレーマー

金が無いくせに口だけ達者

技術に見合った金を出せよクレーマー

片手で操作できる大きさ→大抵出来る

もたつかない待たせないスムースタッチインターフェイス→出来るのに何を?

イヤフォンジャック付きで音楽聴きながら充電できる→おくだけ充電使えよ

日中動画ゲームやっても帰宅までもつバッテリー→持つ。持たないのは使い方が悪い

インスタ映えとかどうでもいいから昼間ならきれいに取れるカメラ画像アプリ自分修正すればいい)→あるだろ

勝手Wi-Fi取りに行かない→お前の設定ミス

着拒や通話録音ができる→出来るよ?馬鹿

アップデート安心してスムーズにできる(Androidみたいに機種によってアプデ時期がバラバラとか論外)→できるけど。スマホに通知くるだろ。

別にそこまで薄くなくていいから100グラムちょい程度の軽さ→今までのスペック上では無理だろ。お前がたくさん金払うなら可能だろうが

割れないもしくは割れても安価に修理できるタッチパネルガラス→は?

それで5万くらい。→は????????

anond:20190912144447

まともなスマフォって作れないの

片手で操作できる大きさ

もたつかない待たせないスムースタッチインターフェイス

イヤフォンジャック付きで音楽聴きながら充電できる

日中動画ゲームやっても帰宅までもつバッテリー

インスタ映えとかどうでもいいから昼間ならきれいに取れるカメラ画像アプリ自分修正すればいい)

勝手Wi-Fi取りに行かない

着拒や通話録音ができる

アップデート安心してスムーズにできる(Androidみたいに機種によってアプデ時期がバラバラとか論外)

別にそこまで薄くなくていいから100グラムちょい程度の軽さ

割れないもしくは割れても安価に修理できるタッチパネルガラス

それで5万くらい。

ただし中韓は不可(爆発したりスパイウェアとか入ってそうじゃん)

あるなら教えて。

2019-09-02

実際VRコクピット座って操縦するゲームとかやった印象

【実機に導入するメリット

・空中にメニュー出せるのめっちゃ便利

複数情報を出して周りに浮かせておくと超捗る

デメリット

HMDが重い。勢いよく振り向くと首ゴキってなる。

(実戦で使うにはスキー用ゴーグルくらいのサイズ必須

・手元が見えない。何か落としたりしたら、もう拾えない。

(半透明モニタMRでいいのでは?)

・激しい動きや振動で外れる。

戦闘の衝撃でゴーグル割れそう。

(万一の事態のために全天球スクリーンを用意すべき……最初からそれでいいのでは?)

【私の意見

全天球スクリーンに周りの映像インターフェイス投影し、

かい情報パイロットの半透明ゴーグルヘルメットMRハンドジェスチャーで表示させるのがいいと思う。

参考までに君の手持ちのMHD、VRヘッドセットVRゴーグルを教えてはもらえないだろうか?

ノーマルViveとトラッカー3点。ベースステーションはまだ2つ。オーディオストラップ無し。

anond:20190831165412

2019-07-25

OSアプリwebサービスインターフェイスが変わると必ず文句言う人

頑固爺の片鱗あるよね

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。

脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。

そしてこれをそのまま発注するかと言われると、多分しないでしょう。

セキュリティお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。

経営層は中々首を縦には振らないでしょう。

会見でも明らかになったことですが、社長ITリテラシはあまり高そうにありません。

こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。

また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。

いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。

削れるものをあげていってみましょう。

例えば、iOSスマホアプリ実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からアクセスは基本不可であるためです。確か。

そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセスインターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います

・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。

プラットフォームも、ベンダによります実施しなくとも良いとも思います

ベンダ説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います

Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います

サーバコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。

そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。

ワイドショーでは「不正海外IPからで、国外からアクセス許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります

実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います

Webサービスですが、ログインログアウト処理は必須でしょう。また、新規登録情報変更、退会処理も重要です。

パスワードリセットどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。

ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。

ただ、NRIにはNRIセキュアというセキュリティに特化した子会社存在しています

もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います

ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。

NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります

別のベンダ発注したことで、抜け落ちた可能性はゼロではないかもしれません。

また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料セブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断セブンに委ねられます

考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・

ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます

特定ベンダと、ツールを用いた定期診断を実施してもらう契約をしていた

この可能性もあるのかなと思います

使ったことはありませんが、SecurityBlanket 365というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツールOSSのものもあればベンダ販売していたり、SaaS提供しているものもあります

OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります

ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。

有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います

SASTになると、RIPS TECH、Contrast Securityなどでしょうか。

上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。

こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。

ただし、社内のエンジニアに任せる事になるため、片手間になってしま可能性があります

また、ツール使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います

・・・とは言ってもセブンにはCSIRT部隊ちゃんとあるんですよね。

https://www.nca.gr.jp/member/7icsirt.html

『7&i CSIRT は、7&i グループCSIRT として設置され、グループ企業に対してサービス提供しています。』と記載があります

また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています

グループ企業情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査分析リスク情報の共有、ならびにインシデント対応活動を行なっています。』

という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。

組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会情報管理委員会のどこかに所属しているんじゃないかと思われます

日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバー専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。

なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います

会見内で言われた二段階認証検討事項に上がらなかったのかなあ・・・と。

まあ、今でも機能しているのであれば、の話ではありますが。

で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。

https://www.7pay.co.jp/news/news_20190705_01.pdf

これを見ると内部のCSIRT機能していなかったか力不足判断されたかどちらかになるのかな・・・と。

実際はどうだかわかりませんけど・・・

診断を実施したがどこかで抜け落ちた

これも有り得る話かなあ・・・と。

関係者が多いと情報共有にも一苦労です。

開発やベンダCSIRT部隊情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧表現で伝わっていなかったとか・・・

ベンダ実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。

問題認識していたが上申しなかった/できなかった

7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48

2019-06-10

さようならMac

MacBook Pro辞めて、Mac Pro買おうかなと思っていたが、いよいよMac熱が冷めた話をしてみたい。

10から5年前くらいまでのMacBook Proは、先進的で、Appleの拘りに共感でき、さらコスパもそこそこだった神製品だった。

ところが、今は、強豪がかつてのMacに追いつき、Appleの拘りにも共感できず、一般的サラリーマンにはちょっと手が出ない価格帯になってしまった。

ということで、私が脱Macした理由を紹介する。

先進

10年前

私はWeb開発をしていて、サーバーOSであるUNIX系のソフトを利用することが多い。MacもまたUNIX系のOSであるため、Web開発の相性もぴったりだった。

Text MateというMacしか動かないエディタ存在した。私はMacをこのText Mateのために購入したと言っても過言ではない。Windowsにも似たような製品はあったが、Text Mateの使いやすさには及ばなかった。

あとは、それまで利用してたWindowsソフトMac版が用意されており、Windows同等に利用できたことも大きかった。

現在

Web開発の主流は仮想化((Dockerが3位。https://insights.stackoverflow.com/survey/2019#technology-_-platforms))。中でもコンテナ型のDockerを使うことが多くなってきた。しかしながら、そもそもLinux上で動かす用途なので((と勝手認識していますが))、Windows版とMac版は速度に難があり。Docker使うの辞めた人もいるくらい((https://shinkufencer.hateblo.jp/entry/2018/05/03/233000))。私も5年前のマシン不自由してなかったけど、Dockerだけ実用速度が出ないときがあって困った。

WindowsUNIX系のソフトを利用しやすくするため、「Windows Subsystem for Linux」といったものを標準で組み込んできた。今度登場する「Windows Terminal」はSSHを利用できるみたい((https://www.itmedia.co.jp/news/articles/1905/07/news080.html))。

Macしか利用できないText Mate以外にも便利な開発ツールが登場した。Visual Studio CodeやIntelli J((10年前にもあったけどな))など。どちらもWin版だけではなくLinux版に対応している。

Appleのこだわり

10年前
現在

価格

Macが高いかどうかは議論余地があるが、Macには選択肢がないってところが大きいかな。

Windows機みたいに5万円切る安いMacも無いし、メモリー増設も出来ないくらメンテナンス性が落ちていると聞くし。

まとめ

いまやMacは、カッコいいんだけど実用性が低いハイブランドに近づいている!

https://twitter.com/qzqrnl/status/923377961285201920

2019-06-09

スマホのダークモードって有料機能にしてええの?

うちの会社はご多分に漏れず零細ITなのだが、作ってるアイポンアプリをダークモードにしようかという話が出ている。こないだのあれでそういう機能がついたからね。インターフェイススタイルとか言われてんのかな、知らんけど。

でもやっぱ対応するのに工数はかかる。今までそんな事考えずにやってきたアプリだとなおさらだ。だからこの機能を有料機能の一つにしちゃわない?という話になっている。

大丈夫なのかな。いや多分審査的には問題ないんだろうけど、世の中的にさ。「ダークモードは福祉!有料なんて反社会的だ!よくも偏頭痛悪化させてくれたな!星1つ!」みたいなレビューで埋まったらどうする。こわいよ。

2019-02-27

[]なんでもスマート……

アイ・ワナビースマート

2019年現在、みんながスマートフォンを持ってる。

老若男女を問わず子供も持ってる。老人も持ってる。

先進国でも、発展途上国でも、みんながこのハイテクな板切れに夢中だ。

スマートフォンだけじゃない。なんでもスマート

スマートウォッチ!スマートグラス!スマートスピーカースマート冷蔵庫

「さぁ、君もスマート○○を手に入れて、もっとスマートになろう」

現代社会は、賢くなければ生き残れない。

スマートフォンはなにがスマートなのか

スマートデバイスの代表例と言えば、やはりスマートフォンだろう。

スマートフォンはフィーチャーフォン(ガラパゴス・ケータイ)と比べて、どこがスマートなのか?

スマートフォンが登場した当初は既存ケータイと比べて「パソコンライク」に扱える印象があった。

パソコンのようにサイトを見ることができ、パソコンのようにマウスキーボード接続でき、パソコンのようにファイルアクセスができる。

フィーチャーフォンはそれらのことが(基本的に)出来なかった。

ケータイパソコンに著しく劣る」という前提からスマートフォンなのである

成功例はスマートフォンだけ?

比較知名度の高いスマートウォッチやスマートグラス、スマートスピーカーであるスマートフォンほどはヒットしていない。

スマートウォッチやスマートグラスは、まぁスマートフォンの周辺機器のようなものだ。

(スマートグラスに至っては盗撮問題解決されない限り普及は困難だろう)

スマートスピーカーは主に裕福層<ブルジョワジー>や最先端技術愛好家<ギーク>が愛用しているにとどまるようだ。

(裕福層は豪邸に住んでおり手足を使わずスイッチを音声コントロールするためスマートスピーカーを買う)

スマートデバイスは無数にあるが大成功といえるのは実質スマートフォンぐらいではないか

他にはスマートフォン人気にあやかった周辺機器がそれなりに売れている程度だろう。

別にスマートでないヒット商品

最近流行商品はなにもスマートものばかりじゃない。

例えばドローンHMD(ヘッドマウントディスプレイ)、VRヘッドセット3Dプリンタロボット掃除機シングルボードコンピュータなどが挙げられる。

これらは別にスマート○○と名づけられていない点が興味深い。

安易スマート○○と名づけてしまうのは方向性が明確でないためではあるまいか

スマートフォンの特異さ

スマートデバイスのネーミングについて考えているうちに思ったことがある。

実はスマートフォンは、他のスマートデバイスと比べても特異なのではないか

スマートフォン以外のスマートデバイスは「非コンピュータ搭載」→「コンピュータ搭載」というコンセプトのものが多い。

しかスマートフォンに限って言えばフィーチャーフォンコンピュータ(SymbianOSなど)には違いなかったはずだ。

(なおガラケーが本当コンピュータなのかについては知識不足により掘り下げて説明することができない)

スマートデバイスの代表スマートフォンは、しかスマートデバイスの中でも特異なのである

スマートな使命

思いついたスマートデバイスは大抵もうある。

スマートペンスマート義肢スマートカー。スマートバイクスマートエレベータースマート監視カメラスマートインターホンスマートドラッグスマートダスト

無数のスマートデバイスが存在する。

皆さん、いくらなんでもスマートに惹かれすぎでは?

から見るとあらゆる業界開発者スマートな使命感に燃えているようである

それにしても製品を作っている当の本人たちは本当にヒットすると思っているのだろうか?

あるいは「これからスマート時代だ。IoT時代だ」という有難いアドバイスのおかげかもしれない。

スマート椅子取りゲーム

スマート○○というネーミングにはひとつ欠点がある。

スマート○○を名乗れるのは早い者勝ち最初ひとつだけなのである

最初ひとつスマート○○をうまく解釈して、うまく顕在化させて、うまくアピールできればヒットする可能性はある。

しかし、いまいちシックリこないもの最初スマート○○を名乗ってしまえば、そこでおしまいだ。

先に商標などを押さえられてしまえば後続者は身動きが取れない。

スマートの今後

新しいスマートデバイスのコンセプトとして、既にあるものスマートにする方向性は厳しいように思える。

なぜならコンピュータを搭載しないで普及したものは、コンピュータを搭載しないでも普及できたためだ。

もし成功するスマートデバイスがあるとするなら、それは恐らくコンピュータを搭載しないと実現できないものだろう。

個人的には「スマートフォンを制御モジュールとしてドッキングする製品」という方向性シフトしていくと予想する。

規格化されたスマートフォンスロットがあり(ファミコンカセットみたいに)スマートフォンを差し込むことで機能をゲットできるという仕組みだ。

(オーディオインターフェイススピーカーなどのジャンルドッキングする製品はすでにある)

スマートデバイスはスマートフォンの一強だということに、みんなそろそろ気づくだろう。

スマートフォンがすごいのならスマートフォンとひとつになればいいというわけだ。

そして……、最終的に人類スマートフォンは同義語となるであろう。

すなわち「ホモスマート」の誕生である

2019-02-07

生体認証増田酢魔うょ心に痛い説は(回文

眠れない夜キミのせいだよ~

はじめての生体認証

つい先日近郊の銀行で口座を開設したのよ。

で、せっかくだから生体認証にしてみたのね!

張り切って行った

初めての生体認証でのATM操作で驚いたのは、

生体認証したとき暗証番号いらないのね!とビビってしまったわ。

暗証番号無しで引き出せるって、

ヤバくない?危なくない?大丈夫なのかしら?って思うわ。

生体認証かーらーのー暗証番号2段階認証かと思ったの。

もうさ、

いつまで人類

ヤシの木の画像クリックしたり、

横断歩道画像クリックしたり、

信号画像クリックしたりしなきゃいけないのよ!と面倒くさいなぁと思ってたら、

生体認証だけで通れちゃったから、

わずATMの近くにいる行員さんに、

あの暗証番号入れてないのに開けちゃったんですけど!って言いそうになったわ。

指をスキャンするとき動作音とかもないか

これちゃんと動いてるのかしら?って思うし。

スパイ映画とかのあるあるなんだけど、

指をスキャンしたら

黒い画面に無駄デカデカ緑色ワイヤーフレームで表示されくるくる回る指先のイメージが出てきて、

マッチングさせる場所

赤い丸がぽわんぽわんと点滅表示されて、

何箇所かマッチングしました!認証OK!って

リアルタイムコンピューターが考えて認証してるんだな感を表現している、

そんなの現実生体認証での画面では一度も見たことないわ!ってぐらい

映画を見てる人に分かりやすいぐらい大袈裟大風呂敷演出生体認証システムな画面だったら

もっと認証感があると思うんだけど、

それなんてイーサンハント!!!って。

映画に出てくるパソコンの画面って

フォント大きいし

インターフェイスの作りもなんか大きいし、

全てのスケールがなんか大きいのよね。

そんなの今時Windowsでもないわよ!って思っちゃうぐらい。

まあそんなのATM生体認証ビックリした話でした!

チャンチャン。


今日朝ご飯

タマサンドとハムサンドにしました。

ミックスにしようか迷ったけどなんとなくハムサンド。

なんか今日はお店の品揃えが冴えない感じね。

デトックスウォーター

リンゴスライス炭酸で割る、

スパークリングアップルウォーターです。

スティールウォーターで作ってもいいわよ。


すいすいすいようび~

今日も頑張りましょう!

anond:20190207101410

言語キャラにするとネタが尽きるの早そうだから言語仕様擬人化しよう。

JavaクラスC#インターフェイス、Cのポインタ、など。

言語間で同じ名前仕様があったりするけどそこは被りアリで。

2019-01-12

タッチパネルが当たり前になった時代

改めて思うのはインターフェイス重要なのは直感であるということ。

もっといえば、直感的でないインターフェイスは低品質ということだ。

こないな話しとりますとつい京都にいらっしゃる人らの事思い出してしまますわ。

あん人らいつまでたってもお公家様みたいなお言葉遣いでほんま江戸しぐさとりますなあ。

2019-01-05

anond:20190105140905

アスペ型の発達障害さんの抱える問題がまさにそれですが、

文脈対話する状態を切り捨てて、

情報だけを入手したいというのなら

すでにSiriアレクサ、オーケーグーグルなどで解決済みなんだよね。

人間に回答してほしいならはてな人検索ヤフー知恵袋サービスもある。

 

インタフェイスいくら進化しても

他人理解できることでも自分けが理解できない。

そのため、自分には適切な社会参加ができない」という問題解決できません。

あなた理解をしなくてはいけない。

 

あなた自身社会流通しているいろんな論理価値観をおぼえなくてはいけないだけ。

複雑な人間というものを覚えるのが学校

 

人間簡単モデルにしてみせて複雑な人間関係への発達を阻害しているのが

ゲームなどコンシューマー向けコンピューターサービス

コンピューターサービスインターフェイスはもうこれ以上ないほど発達しているか

アスペ発達障害でもゲームなら簡単に進行できる人が多い。

でも現実ゲームにしてアスペ発達障害にさしだしてあげることはだれもできない。

2019-01-03

anond:20190103184241

// WindowsProject7.cpp: アプリケーションエントリ ポイント定義します。
//

#include "stdafx.h"
#include "WindowsProject7.h"

#define MAX_LOADSTRING 100

// グローバル変数:
HINSTANCE hInst;                                // 現在インターフェイス
WCHAR szTitle[MAX_LOADSTRING];                  // タイトル バーテキスト
WCHAR szWindowClass[MAX_LOADSTRING];            // メイン ウィンドウ クラス名

// このコード モジュールに含まれ関数宣言転送します:
//ATOM                MyRegisterClass(HINSTANCE hInstance);
BOOL                InitInstance(HINSTANCE, int);
LRESULT CALLBACK    WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK    About(HWND, UINT, WPARAM, LPARAM);

#include <list>

class MyWindow;
	
std::list< MyWindow *> windows;

class MyWindow
{
public:

	HWND hWnd;



	MyWindow()
		:hWnd(NULL)
	{
		windows.push_back(this);
	}

	virtual ~MyWindow()
	{
		std::list< MyWindow *>::iterator it;
		for (it = windows.begin(); it != windows.end(); it++)
		{
			if (*it == this)
			{
				windows.erase(it);
				break;
			}
		}
	}

	static MyWindow * find(HWND key)
	{
		std::list< MyWindow *>::iterator it;
		for (it = windows.begin(); it != windows.end(); it++)
		{
			MyWindow *target = *it;

			if (target->hWnd == key)
			{
				return target;
			}

		}

		return NULL;
	}



	//
	//  関数: MyRegisterClass()
	//
	//  目的: ウィンドウ クラス登録します。
	//
	ATOM MyRegisterClass(HINSTANCE hInstance)
	{
		WNDCLASSEXW wcex;

		wcex.cbSize = sizeof(WNDCLASSEX);

		wcex.style = CS_HREDRAW | CS_VREDRAW;
		wcex.lpfnWndProc = WndProc;
		wcex.cbClsExtra = 0;
		wcex.cbWndExtra = 0;
		wcex.hInstance = hInstance;
		wcex.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_WINDOWSPROJECT7));
		wcex.hCursor = LoadCursor(nullptr, IDC_ARROW);
		wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
		wcex.lpszMenuName = MAKEINTRESOURCEW(IDC_WINDOWSPROJECT7);
		wcex.lpszClassName = szWindowClass;
		wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

		return RegisterClassExW(&wcex);
	}

	//
	//   関数: InitInstance(HINSTANCE, int)
	//
	//   目的: インスタンス ハンドルを保存して、メイン ウィンドウ作成します。
	//
	//   コメント:
	//
	//        この関数で、グローバル変数インスタンス ハンドルを保存し、
	//        メイン プログラム ウィンドウ作成および表示します。
	//

	int blocks[100][100];

	BOOL InitInstance()
	{
		hInst = hInstance; // グローバル変数インスタンス処理を格納します。

		ATOM c = MyRegisterClass(hInstance);
		x = 0;
		y = 0;
		boxType = 0;

		hWnd = CreateWindowW(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
			CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, nullptr, nullptr, hInstance, nullptr);

		for(int x = 0 ; x < 100 ; x++)
		{
			for (int y = 0; y < 100; y++)
			{
				blocks[y][x] = 0;
			}
		}

		if (!hWnd)
		{
			return FALSE;
		}

		return TRUE;
	}

	BOOL ShowWindow()
	{
		BOOL ret;
		ret = ::ShowWindow(hWnd, SW_SHOW);
		::UpdateWindow(hWnd);

		return ret;
	}


	HINSTANCE hInstance;
	MSG msg;
	BOOL run;
	int x;
	int y;
	BOOL Main()
	{

		HACCEL hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_WINDOWSPROJECT7));
		run = true;
		int rc;
		// メイン メッセージ ループ:
		while (run)
		{
			DWORD obj = MsgWaitForMultipleObjectsEx(0, NULL,  100 , QS_PAINT| QS_ALLEVENTS,0);
			if (obj <= WAIT_OBJECT_0)
			{
				while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
				{
					if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
					{
						TranslateMessage(&msg);
						DispatchMessage(&msg);
					}
					if (msg.message == WM_QUIT) {
						run = FALSE;
					}
					if (msg.message == WM_CLOSE) {
						run = FALSE;
					}

				}
			}
			else if (obj == WAIT_TIMEOUT)
			{
				y++;
				PAINTSTRUCT ps;
				HDC hdc = BeginPaint(hWnd, &ps);
				this->OnPaint(ps);
				EndPaint(hWnd, &ps);
				::UpdateWindow(hWnd);
				RECT Rect2 = { 0,0,48*9,48 * 100 };
				InvalidateRect(hWnd, &Rect2, TRUE);
			}
			else if (obj == WAIT_FAILED)
			{
				rc = GetLastError();
			}
			else {

			}
		}


		return TRUE;

	}

	int boxType;

	BOOL WriteBoxOLDBox()
	{
		int width = 24;

		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 48, 48));
		for (int y = 0; y < 30; y++)
		{
			for (int x = 0; x < 8; x++)
			{
				if (blocks[y][x] == 0)
				{
					continue;
				}

				RECT Rect = { 0,0,48,48 };
				BOOL ret;

				Rect.left = width * x + 1;
				Rect.right = width * (x + 1) - 1;
				Rect.top = width * y + 1;
				Rect.bottom = width * (y + 1) - 1;

				ret = FillRect(hdc, &Rect, hBrush);


			}
		}

		DeleteObject(hBrush);

		return FALSE;
	}


	BOOL WriteBox()
	{
		WriteBoxOLDBox();

		switch (boxType)
		{
		case 0:
			return WriteBoxI();
		case 1:
			return WriteBoxL();
		case 2:
			return WriteBoxZ();

		}

		return TRUE;
	}

	BOOL WriteBoxZ()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 48, 246));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) - 1;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) - 1;

		ret = FillRect(hdc, &Rect, hBrush);


		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.left += width;
		Rect.right += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);


		DeleteObject(hBrush);

		return TRUE;
	}


	BOOL WriteBoxL()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 246 , 48));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) -1 ;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) -1;

		ret = FillRect(hdc, &Rect, hBrush);


		Rect.top    += width; 
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.left   += width;
		Rect.right  += width;
		ret = FillRect(hdc, &Rect, hBrush);

		DeleteObject(hBrush);

		return TRUE;
	}

	BOOL WriteBoxI()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB( 246 , 48 , 48));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) - 1;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) - 1;

		ret = FillRect(hdc, &Rect, hBrush);


		//Rect.left   += width;
		//Rect.right  += width;
		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		DeleteObject(hBrush);

		return TRUE;
	}

	BOOL SaveBoxI()
	{
		blocks[y  ][x] = 1;
		blocks[y+1][x] = 1;
		blocks[y+2][x] = 1;
		blocks[y+3][x] = 1;
		return TRUE;
	}


	BOOL OnPaint(PAINTSTRUCT &ps)
	{
		if (x > 8) {
			x = 0;
		}
		if (x <0) {
			x = 8;
		}
		if (y > 20) {
			switch (boxType)
			{
			case 0:
				SaveBoxI();
				break;
			case 1:
				break;
			case 2:
				break;
			}

			y = 0;
			boxType++;
			if (boxType > 2)
			{
				boxType = 0;
			}
		}

		this->WriteBox();

		return TRUE;
	}



	BOOL OnKey(WPARAM wParam)
	{
		if (wParam == VK_LEFT)
		{
			x++;
		}
		if (wParam == VK_RIGHT)
		{
			x--;
		}
		return TRUE;
	}


};


int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
                     _In_opt_ HINSTANCE hPrevInstance,
                     _In_ LPWSTR    lpCmdLine,
                     _In_ int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);

    // TODO: ここにコードを挿入してください。

    // グローバル文字列初期化しています。
    LoadStringW(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
    LoadStringW(hInstance, IDC_WINDOWSPROJECT7, szWindowClass, MAX_LOADSTRING);
    //MyRegisterClass(hInstance);



	MyWindow win;



	win.hInstance = hInstance;

	// アプリケーション初期化を実行します:
	if (!win.InitInstance())
	{
		return FALSE;
	}

	BOOL ret;

	win.ShowWindow();

	ret = win.Main();

	if (ret)
	{
		return 0;
	}else {
		return (int)win.msg.wParam;
	}



}






//
//  関数: WndProc(HWND, UINT, WPARAM, LPARAM)
//
//  目的:    メイン ウィンドウメッセージを処理します。
//
//  WM_COMMAND  - アプリケーション メニューの処理
//  WM_PAINT    - メイン ウィンドウの描画
//  WM_DESTROY  - 中止メッセージを表示して戻る
//
//
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    case WM_COMMAND:
        {
            int wmId = LOWORD(wParam);
            // 選択されたメニューの解析:
            switch (wmId)
            {
            case IDM_ABOUT:
                DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
                break;
            case IDM_EXIT:
                DestroyWindow(hWnd);
                break;
            default:
                return DefWindowProc(hWnd, message, wParam, lParam);
            }
        }
		break;
	case WM_KEYDOWN:
		{
			MyWindow *target = MyWindow::find(hWnd);
			target->OnKey(wParam);
		}
	break;
    case WM_PAINT:
        {
            PAINTSTRUCT ps;
            HDC hdc = BeginPaint(hWnd, &ps);

			MyWindow *target = MyWindow::find(hWnd);
			target->OnPaint(ps);


            // TODO: HDC を使用する描画コードをここに追加してください...
            EndPaint(hWnd, &ps);
        }
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

// バージョン情報ボックスメッセージ ハンドラーです。
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    UNREFERENCED_PARAMETER(lParam);
    switch (message)
    {
    case WM_INITDIALOG:
        return (INT_PTR)TRUE;

    case WM_COMMAND:
        if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
        {
            EndDialog(hDlg, LOWORD(wParam));
            return (INT_PTR)TRUE;
        }
        break;
    }
    return (INT_PTR)FALSE;
}

ログイン ユーザー登録
ようこそ ゲスト さん