「設計思想」を含む日記 RSS

はてなキーワード: 設計思想とは

2019-06-19

パラディンズというオーバーウォッチによく似たゲーム感想

結論から言うと

オーバーウォッチよりカジュアル向けだがランクマッチのやたら意識高い仕様台無しにしている。

ランクマッチへの参加はオーバーウォッチより難易度が高い。

どうしてカジュアル

ラインハルト(とゴリラ)がいないから。

OWというゲームラインハルト(とゴリラ)が強すぎる。

ゆえに盾を割りあうかダイブで荒らすかの二択しかない。

そしてこの2キャラ難易度が高く極めてストレスフルでもある。

そのくせして必須

『OWから逃げる』のは大抵この二大メインタンクから逃げている。

パラディンズのフロントラインタンクに相当する)も必須ではあるし、やっててむかつくことも多いのだがOWよりはだいぶましだと感じた。

そこそこの攻撃力、機動力が与えられているためだろうか。OWでいうフレックスに近い。

多くのフロントに発動の早い短距離ダッシュがあるのは興味深い。

またサポート比較的使いやす戦闘も十分できるものがそろっている。

性奴隷マーシーのようなクソキャラがいない。

シンメトラのようなヒールできないサポートもいない(ピップがやや怪しげだが)。

ヒーラーなのにリーパーめいた性能のいい無敵逃げ技があったり、竜が敵を食らうみたいな技持ってたりする。

フロントサポート担当もなるべく気持ちよくさせようという設計思想があるように思える。

メインとなる種目はOWで言うコントロールエスコートが組み合わさったようなもの

悪名高いアサルトがない。

アサルトがないことが影響しているのかラインハルトがいないせいなのかこのゲームはいわゆるガバディがほとんどない。

良くも悪くも全員突っ込んで行く。

なぜかスナイパーまで突っ込んで行く。

さらにはサポートまで突っ込んで行く。

だがランクマッチピックルールで台無し

私はlolを知らないのだが本式のMOBAに近いルールのようだ。

パラディンズのランクマッチでは最大4キャラがBANされる上に、敵味方全体でキャラ被りできなくなっている。

さらに並びで上の人から順番にピックしていくようになっている。

まり好きなキャラが使える可能性がかなり低くなっている。

一応味方同士でトレードできるが応じてくれるとは限らない。

敵がとったキャラは使えなくなるので重要キャラはいち早くピックしなければならない。

自分が使えないキャラであってもだ。トレードしてもらえることを祈るしかない。

クソピックしようものなら袋叩きだろう。

そもそもマッチングするまでの時間自体が長くさらにこのピック会議も長い時間を取る。

これでクソ試合になろうものならストレス半端ないものになるだろう。

実際、配信を見てもしょっちゅうリスポンルーム喧嘩している。

このやたら意識高い本格的なピックシステムから競技性への強い未練を感じる。

参加するだけならたやすいOWのライバルマッチとは正反対だ(参加した後の精神と毛根は保証しない)。

あとがき

残念なゲームである

もっと思い切ってカジュアルによせればOWに心砕かれた難民の受け入れ先になっていたかもしれない。

クイックで自己中心的プレイをする分にはリーズナブルなゲームではある。

なにせ無料だし。

2019-06-06

anond:20190606065400

ガンダム」とは、地球連邦軍が開発したモビルスーツ RX78 および、その設計思想を受け継ぐモビルスーツ総称である

ガンダム」という機種には、正義も悪もない。搭乗するパイロット所属する組織正義として描かれるか、悪として描かれるかによる。

味方にとっては頼もしいが、敵対する組織の兵にとっては「白い悪魔である。「機動戦士ガンダム」では、ジオン公国・ザビ家が地球連邦に対する悪と位置づけられてはいる。「機動戦士Ζガンダム」ではガンダムmkⅡはティターンズの機体として搭乗する。

ガンダム作品群においては、明確な正義と悪は存在せず、勢力対立が描かれている。主人公側でない組織が概ね悪であるが、上層部どっちもどっちである

2019-05-21

anond:20190521094742

プッシュダガー設計思想いからその形状なら刺しやすそう。同じ発想でいくなら消しゴムを横向きに握りしめて、腹部分に針やペンを立てて指の間から出すようにしたら確実に力を伝達できるよ。骨がない顎下から打ち上げれば脳幹まで狙えるってなんかで見たような気もする。

2019-04-08

ほぼ全てのゲームチュートリアル自体か、その直後、普通プレイ動画なら30分もかからず超えていくようなところで数ヶ月行き詰まって挫折するのをひたすら繰り返してきた自分からすれば、難易度なんか制作サイドの好きにすればいいと思う。どんな難易度設定のゲームでも自分にとってはクリアすることが不可能な死にゲーだから

話題になってるフロムに限らず、はてなー大好き任天堂なんかも大昔から、下手くそにはゲームプレイする資格なしという設計思想だし今更何言ってるんだろう感ある。

上達のために失敗の度にひたすら自分を殴り続けて鼻血だしたり、壁や床に頭を打ち付けて気絶したり、顔を殴る位置が悪いのか難聴気味になったりしてるけど不思議と一向に上手くならない下手くそ自分フロム任天堂スタッフからすればプレイして欲しくない唾棄すべき存在なんだろうなと思いつつ、プレイさせてもらえるだけありがたいと感謝して今夜も自分を殴る。

2019-04-03

anond:20190403041610

まあ所詮外注だし

(と思って1年以上経ったが)

 

つうか外注は内製達がやりたい設計思想トレースしてあげなきゃいけないから地味に難易度高いな

プログラマーの悩み

今一緒にコード触ってる人と、設計思想が合わない

思想レベルで違うとプルリクでえぐい修正が入る

まあよくある話だけど

設計思想議論したいけど、なんかめんどくさい

それが良いかどうかより、他で使われてたかどうかを重視するから

なんかそこからして思想が違う

ていうかおっそんの俺は付いていけるけど、これ若手は理解できないだろ

2019-01-07

昔の学校イメージ

 私たち平成世代の側の人間は、学校ロマンスを求めてしまうが、偏差値上下を問わずに、本来教育のための施設しかなく、細やかな教育手法対応できるものではない。

 それでいて、学校教育支援よりもよほど便利なシステム予備校などすでにいくらでもあるので、細やかなアップデートを図られることなく、用途の短縮ばかりが進み本来設計思想と相容れない運用がなされ、益々何のための施設なのかさっぱりわからなくなり、自滅しているのである

 こういうと私たちには耳の痛い話だが、学校NIMBYでもあった。ゆえに、住宅地の片隅にしか学校が作られなかったし、学校数も少なく抑えられた。戦前時代、あの施設軍隊的な指導しまくっていたのだから、近隣住民からすればたまったもんじゃない。しかボール飛び出し防止ネットはあまり完備が進んでいなかったので、野球のたびにボールがあちこちに飛びまくっていた。文化的イメージは後から追加されたものに過ぎず、もし我々が戦前戦時中時代人間だったなら、たぶんあん施設嫌いになるんじゃないかと思う。

2018-12-18

anond:20181218104101

実際に「Chromeより30%省メモリ」を謳ってるし、むしろFirefoxChrome設計思想が一緒になった時代がないぞ。

まあ本腰入れて調査してないけど、Chromeってタブ幅の固定すらできねえだろ。論外だよ。

anond:20181218103637

メモリの部分、おそらくどの時代においてもchrome設計思想が一緒な関係で省メモリ指向になった時代存在して無いはずなんだが。

カスタマイズが容易って、それ他のブラウザ比較して言ってんのか?

おめーがただ趣味firefox使ってる以上の優位性はねえよ。

最低限リモートデスクトップ積んでから来いやあ…

2018-11-17

anond:20181117114626

Androidを6年使ってきて先月iPhone 8に乗り換えた人間私見

実際はそこまで不便じゃなかったり好みが大きく入っていたりするところ


本当にクソなところ


逆にiPhoneが優れているところ


個人的結論としてはFGOをやめさえすれば本当にどっちでもいいなという感じ.

文字入力ストレスなくできる点ではAndroidの方が好みかも.

2018-11-09

anond:20181108133127

すごく面白いな。多品種少量生産製造業付加価値を出していくには、バリエーション出す土台となる、ある程度シンプル生産設備があるということなのだろうか。

スコットランド博物館で初期の蒸気機関を見たことがあるんだけど、もう天井に届きそうなくらい、とにかくでかいんだ。プリミティブな機械って、部品がそれぞれ独立性が高くて、ゴツゴツとおおざっぱに大きいということがよくわかる。

機械が洗練されていくにしたがって、機能がしっかり分節された部品同士の有機的な結合度合いが高まって、見た目にはコンパクトシームレスで美しいんだけど、素人が触ると、ぎりぎりのところで成立しているバランスがすぐに壊れてしまう。メーカー側の想定範囲内のチューニングしか動かないようになっている。コンピュータも道具としての洗練度が高まるにつれて、そういう方向に向かっているように思う。

ユーザーがあれこれカスタマイズして試せるようにするには、そうすることを最初から設計思想に取り込んでいくしかないのだと思う。Raspberry Piとか、IOTデバイス高級言語コーディングで作れるブロックとか、カスタマイズを前提としたコンピュータは、昔ながらのいわゆるパーソナルコンピュータとは別方向に進化を始めていて、これはこれで、PCとは別の使いこなし方を要求しているように見える。難しそうだな、と思ってたけれど、こういう製造業の人たちの創意工夫を見て、なんだか自分セルフビルドしてみたくなってきたよ。

2018-11-02

anond:20181102165640

シェイプが使えるのかjoint限定なのかエンジン側の仕様にもよるし

モデル設計思想にもよる。

そういう事考えないならシェイプが理屈の上ではいいんじゃない?

2018-09-01

甲子園球数制限とかそういう話

夏の甲子園“投手ぶっ壊しコロシアム”の解体方法──スポーツとしては時代遅れ、教育としてもデタラメ

 だが、そうするとべつの問題が生じる。

 ピッチスマートでは17~18歳は105球を上限とされているが、100球ちょっとで9回を完投できることはさほどない。よって継投を余儀なくされる。そうすると、2番手投手の力が劣るチームは不利となる。

 ただ、日程に余裕をもたせる提案も、抜本的な解決にはほど遠い。そもそもトーナメント戦で一発勝負であることが、野球というスポーツにはそぐわない。プロスポーツ優勝者勝率もっとも低いのは、6割程度の野球だと言われている。10回やって4回負けるチームが優勝する。これは試合数の多さも関係しているが、運に左右される傾向があることも意味している。高校野球ファンプロ野球ファンがかならずしも重ならないのはこのためだ。

この2つが同じ記事内に共存するのか(困惑

一発勝負の勝ち抜きトーナメントだと、強いチームの思わぬ不調や弱小チームのまぐれなんかで、弱小チームが勝って強豪チームが負ける番狂わせが起きることがある。それを嫌って、長期的な勝ち負けの記録を積み重ねて成績を決めよう、というのがリーグ戦だ。

この2つはどちらが悪いわけでもなく、単なる設計思想の違いである。実力が明らかに格下の相手に偶然が重なってたまたま負けてしまったばかりに大会敗退を余儀なくされた強豪からすればリーグ戦の方がありがたいだろうし、わざわざスタジアムまで足を運んでチケット代を払ったのにやる気のない消化試合を見せられた観客からすればトーナメント戦のドラマ性に魅力を感じることだろう(サッカーW杯ポーランド戦は記憶に新しい)。

そう、選手層が薄いチームにとって有利なのはトーナメント戦であり、選手層が厚いチームにとって有利なのはリーグ戦なのだ

別にどちらを支持しようともそれ自体では何の問題でもないが、継投制限をするなら選手層が薄いチームにとって不利になる、という主張と、トーナメント批判を同一人物が同じ記事で行っているのは理解に苦しむ。

球数制限を課し、リーグ戦を導入したならば、選手健康は守られるかもしれないが、選手層の厚い私立高がますます有利になり、甲子園に出てくるのは「プロ部活」ばかりになるだろう。

逆に球数制限を課さず、トーナメント方式を維持するならば、選手には大きな負担がかかるかもしれないが、選手層が薄くとも一発逆転の目があることになり、「昭和野球」が勝ち進む余地が生まれてくるだろう。今回の金石農業のように。

球数制限試合方式も、それぞれは独立したオプションのように見えるかもしれないし、実際ある種の人にとってはそうだろう。それは、どのようなチームが有利になるのが望ましいのか、という視点を持たない人だ。その視点を持たないならば両者は別々のオプションとして扱って美味しいとこ取りをして何ら問題あるまい。

しかし、「選手の獲得や育成にお金をかけられる私立高ばかりが有利になるのが本当に望ましいのか」という問いを立てるならば話は別だ。そのような視点から語ろうとするならば、球数制限試合方式は切り離せないセット販売だ。

もしも「球数制限を課し、リーグ戦を導入」というセットを購入すると決めたなら、自動的に言うべきことも決まるはずだ。「プロ部活が有利になってしまうという批判があるが、それは仕方ない。都市部私立高が勝ち進み、地方公立校が早々に敗退するような制度を支持する」

なのに、そのセットを購入すると表明しておきながら、選手層の薄い学校には酷だ、なんて同じ記事で言うのは理解できない。都会のスマート自由主義か、田舎の泥臭い平等主義か、どちらを支持するのかハッキリしてほしい。

2018-07-29

エクセル表計算ソフト「ではない」

ある物が何であるかは設計思想ではなく使われ方の実態をもって決まる。

設計思想通りに使ってもらえないのは設計が徹底していないからだ。

エクセルは明らかに表計算ソフトとして使われていない。

いや、表計算は数ある機能のうちのひとつとして重宝されてはいるが、実体もっと複雑で、

DTPソフトでもあり、DBでもあり、メモ帳でもあり、電卓でもあり、プログラミング言語でもあるような

エクセル」というオンリーワン統合ビジネスソフトになり果てている。

そもそも表計算ソフトとはなんなのか?

エクセル表計算ソフトです!」と主張する人に限ってそれを説明できていない。

取引記録や伝票のようなマスタを保持するのはデータベース仕事だ。

それに対し適当な加工をかけるのも本来クエリでやるような話である

まり、「エクセル表計算ソフトからDTPとして使うんじゃねえ!」と叫ぶ人は、

まったく同じ理屈により、エクセルデータベースとして使うことも否定しなければならない。

文書ワードで、DTPパブリッシャーでと言うのなら、マスタはアクセス管理しなさいとなる。

それならもはやエクセル仕事なんてない。

表計算ソフトとは「表」+「計算ソフトなのだ

表とはただデータを保持するものではない。データを「表示」するものである

まりその概念には見栄えという要素も含まれる。

表はデータを整列し、計算し、出力する全ての機能を備えていなければならない。

当然、DTP的な要素もあればDB的な要素もあってしかるべきだ。

そういった全ての要素が結びつき、さらにその上にVBAが乗っかることによってエクセル

エクセル以外のどのソフトにも互換できないような唯一無二の使い勝手を生み出しているのだ。

実際上手いエクセルユーザーの作ったブックは芸術的だ。

表計算でもDTPでもDBでもスクリプトでもあることによって発生する独特の使い方のコツというのがあり、

それはそれぞれ単体のソフトだけを連携させている時には絶対に役立たないようなセンスだ。

自動車の操縦のように、エクセルというソフトを手に馴染ませる必要がある。

からDTP的な使い方しかできていないようなエクセルユーザーに対して指摘する時は

表計算ソフトとして使え」ではなく、「エクセルとして使え」というべきだ。

DB計算ソフトとしてしかエクセルを使っていないのであれば、実のところDTP使いしかできない人と大差がない。

2018-07-14

anond:20180713115153

ブコメ自分が付けた星一覧ページは既にあるだろ。

こうやって、サービスをまともに理解できてすらいない奴がクレームつけてるのが害悪なんだよな。

運営側にも「設計思想よりクレームに応えるほうが大事」と思ってるアホがいるから。

スターを連打できないようにしてください」とかさ。

なんのためにスターがあると思ってんだよボケ

anond:20180713163521

アホか。

スター設計思想からし評価システムに流用するのは向いてないんだよ。

ましてやマイナスなんてもってのほか

そもそも人気のブコメなんてピックアップする必要があるのかというところから自問しろ

2018-06-25

はてなブックマークシステム自体マウントの取り合いに使われてるから

設計思想は知らんけどどうやら相性バツグン過ぎた

そりゃいずれこういう事も起きる

2018-05-06

MicrosoftWindows10を随時アップデートしたいというなら、もうそれでいい。

だがアップデートのたびにそれまでの設定を初期化するのはやめてほしい。

Windows10は使いにくい」この事実に対しMicrosoftは一度正面から向き合うべきだ。

設計思想更新思想機能追加ばかりで、ユーザビリティ無視した結果だ。もう付け焼刃じゃ直らない。

かっこよさとユーザビリティを追及したものであれば、OSXのように「Windows」でなくてもいいのだ。

やいところ最初から作り直した新しいOSなりウィンドウマネージャなりを提供してほしい。

2018-04-20

anond:20180420124830

Eugenがマストドン作った思想的にはその通りなんだけど、一時期Twitterに置き換わるサービスって言われてたくらい盛り上がったのに終息しちゃったのは何でかなと

そもそも設計思想からし流行らせる目的じゃなかったからって言われたらそれまでだから流行りかけた事自体おかしかったでFAなのかな

2018-03-04

休日コーディングしてる人生負け組

try! Swiftが終わった。

オナニー同然のくだらないゴミ発表が一部あったのは残念だ。

そんな中、Krzysztof Zabłockiの発表は耳新しい話こそ無かったがなかなか良かった。

彼はiOS黎明期から数々の有用ツールライブラリを公開してるすごいオッサンだ。

そんな彼のGithubプロフィールを見て愕然とした。

https://github.com/krzysztofzablocki

おいおい。土日のコーディングをほぼしてないじゃないか

どういうことだ?

プログラマなんてものはどうしようもなくプログラミングが好きで、

常に頭の中ではまだ見ぬ設計思想を基に、まだ知らぬプログラムを作っているものだろうが。

当然コントリビューショングラフ大草原で決まりだろうが。

それなのにコイツは何だ?

いやコイツだけじゃない。

一部の成果あるプログラマは土日ほぼコーディングをしていない。

なんだあいつら。バケモノか?

業務時間中だけで内外ともにすばらしい成果を残し、土日は完全に楽しんでいるんだ。

それに比べ俺は何なんだ。

時間ばかり使い、大した成果も出せず、大勢を前に発表できるネタもなければ、誰も見向きもしない。

完全に負け組だ。

あのオッサンと俺、どちらが人生を楽しんでるかなんて聞くまでもない。

俺も彼らのようになりたい。

なれるのだろうか。

2018-02-25

pythonって一貫性なさすぎじゃない?

いや、実用的で素晴らしい言語だと思うよ。

でもさ、なんか一貫性が無いように感じるんだよね。

まず、言語の大半の部分がオブジェクト指向言語っぽいデザインになってるのに、listの要素数を測る手段len()って*関数*なのはどうなの?

(しか略語って...)

a = [1, 2, 3]
len(a)  # 3

他にもあるよ! pythonくんのアレな所

俺は、sortとsortedって言う命名からこの挙動をまったく予測できなかった。

  • 破壊的変更をする list.sort()
a = [1, 3, 2]
a.sort()  # None
a  # [1, 2, 3]
sorted([1, 3, 2])  # [1, 2, 3]

しかもsortedにdictを渡すとkeyがlistに変換されてソートされて返ってくる。

コードリーダビティに関する本を開けば、どの本にだって「良い名前選択する」ことの重要性が書かれていると思う。

「sort()が破壊的で、sorted()が非破壊的、sorted()にdictを渡すとkeyのlistがソートされて返ってくる」これって良い命名なのかな?

pythonくんってこう言う所あるよね

配列の要素を文字列連結

", ".join(['1', '2', '4', '8', '16'])  # "1, 2, 4, 8, 16"

えーっ、join()のレシーバー区切り文字って…引くわー

しかも、これに対する「文字列リテラル (文字列定数) のメソッドを使うのは*醜すぎる*」という意見に対しての公式の返答が、これってのも凄い。

かにそうかも知れませんが*文字列リテラルは単なる固定された値に過ぎないというのが答えです。文字列に束縛された名前メソッドが許されるなら、リテラルに使えないようにする論理的理由はないでしょう。

https://docs.python.jp/3/faq/design.html#why-is-join-a-string-method-instead-of-a-list-or-tuple-method

The Zen of Pythonで「醜いより美しい方がいい」って言ってましたやん。

そもそもリテラルかどうかに関係なくstrインスタンスにこのメソッドがある事がおかしいと思った。

なんでpythonくんって一貫性ないの? pythonくん「歴史です」

pythonmap関数として実装されている。(まただよ...)

list(map(lambda x: x*x, [1, 2, 3]))  # [1, 4, 9]

なんでメソッドにしなかったの? って質問に対して公式がこう答えてる。

主な理由歴史です。複数の型に対しての総称的な操作で、対象オブジェクトメソッドを全く持っていなかった (例えば、タプル) としても働くよう意図したもの関数は使われました。

(中略)

個々のケースについては粗探しのしようがありますが、Python の一部であるし、根本的な変更をするには遅すぎます

https://docs.python.jp/3/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list

うわー、信じられねぇ…

歴史的経緯があるから一貫性が無いのは仕方ないみたいなこの感じ。

これが設計思想に「醜いより美しい方がいい」を掲げるpython実装なんだねぇ…

pythonくんの良い所

散々pythonの事を悪く言ったけど、おれ実はpythonくんの良い所もいっぱい知ってるんだ。

pythonくんの良い所:

ライブラリが超充実してる!
インデントコードブロック表現する文法クール!
PEP8という規約であるべきコードフォーマットを明示したのが良いよね。
Cythonで高速化楽ちん!
namespaceが使いやすい! デコレーター便利!

美しくない、それゆえに強いプログラミング言語python

The Zen of PythonPython設計思想が色々書いてある。

「醜いより美しいほうがいい」という指針があることはさっき紹介した通りだ。

pythonがそれを体現してるとは、僕にはどうも思えない。

でもThe Zen of Pythonには「Although practicality beats purity.(実用性を求めると純粋さが失われることがある。)」とも書いてある。

pythonはこの設計思想を他の言語には無い高いレベル体現してるとは思う。

pythonは、

節操に色々取り入れた上で、「tupleからメソッドはやせないから、map関数にする」とか、メチャクチャ方法でそれらを統合した言語だ。

だが、そういう言語からこそ、pythonで書いたコードを育てていく中で様々なパラダイムへとシームレスに変化させていく事ができる。

そういう「不純であるがゆえに柔軟性を持ったプログラミング言語pythonだと思う。

ruby純粋性はすごいよ。イカれたくらい徹底されたオブジェクト指向

BaseObjectをrootとする継承のツリーの中に世界のすべてが収まっている。

haskell純粋性も凄い。「代入が無い」プログラミング言語に初めてであった時の衝撃。

でも、そういう純粋性をかなぐり捨てたpythonにはタブーが無い。

不純で醜い、それゆえに強い言語python.

から僕はrubyとの思い出を反芻し、haskellに焦がれながら、明日pythonを選び、書いていく。

2017-11-28

anond:20171128122928

”うーん、やっぱり君の理解度が足りないのか俺の話し方が悪いかだな”

そうですね、あなたの話すトピックや言っていることも支離滅裂ちょっと僕の理解度が追いつかないかな。ごめんね。僕の理解が足りなくて。

”俺はスマホの方が優れてるのを認めつつも進化方向性として入力・出力を切り分けたモバイル存在するべきだったという話を最初からしていた”

もう一度読み返してみ?あなたのいうスマホガラケー進化ってそれだけですか?

用途に合わせて色々用意しなきゃいけなくなった時点で道具としての価値付属品が増えるほど落ちるよ”

mp3プレイヤーカーナビビデオレコーダーカメラDVDプレイヤー電子マネーラジオATM地図帳、時刻表腕時計カレンダー付きの手帳メモ帳辞書。パッと思いつくだけ書いて見ましたがこれだけのものスマートフォンがぶっ飛ばします

必要な物だけ使えばいいだろというけどその人にとって必要な物っていうのは必需品であってスマホキーボード必要になった時点でガラケースマホ比較ガラケースマホキーボード評価になる”

全然違う。ガラケー予選落ち比較にすらなってないよって話をずっとしてる。

可能性の話をするときに現状の見えている範囲しか話ができない人間は成長性もないし開拓も開発もないとつくづく思うよ”

君の思いつく理想携帯像はこうだって話だったらもっと面白かったかな。現状に対して不満しか言ってない君が可能性の話をするなんて笑えるよ。

”きっとスマホが出る前はガラケーがどんだけ素晴らしいのか力説してたんだろうけどー”

ガラケーなんて使わずにG's Oneっていうカシオの防水携帯を何年も使ってました。白黒画面で1円で高校生の時に買った携帯ですね。ガラケー価値見出してませんでしたし。

”やってることはゲームDLC商法と同じで最初から機能つけなくても不満なくニコニコ現金払いしてくれる馬鹿を増やす仕組みだからiPhoneブランディングに力入れたんだよ”

何千何万っていうアプリを”アップル”が全部開発してそれが機種代にどのぐらい影響するかな?後、DLC商法別に悪くないでしょ。市場原理主義携帯アプリケーションにも適用されただけ。アンドロイドアップルがそれぞれしのぎを削ってくれればそれでよし。それを使いこなせない馬鹿が増えても別になんとも。

”せいぜいカメラの性能とか通信速度やバッテリーで張り合うくらいで虚しさしかない。画面がでかくなった!”

デバイスの過度な性能競争が虚しいのは同意ですね。ですけど、性能が上がることによって今までできなかったことができるようになることはあるから自分の使いたい機能と性能を選べばいいんじゃないかな?パフォーマっていうパソコンから使い始めて、アップルアップルコンピューターって名前だった時からアップル信者だけど、中華製の防水AndroidiPhone5c使ってるよ。

周辺機器全込みの金を最初からだすから全部機能ついてるスマホ出してくれよ”

それパソコンでも同じこと言える? 田舎電気屋でこのパソコンエクセルついてる?っていうのと感覚全然うからね?

必要になるたびに買うとか繋げるとか持ち運ぶという二度手間を何度も強要するのが効率的先進的?

それ間抜けとどう違うんだ。栓抜きでさえ多機能で揃えてきてるのに栓抜き以下の設計思想スマホだよ”

モジュールって考え方を勉強したら少しはわかるようになるんじゃないかな。必要機能ダウンロードして使えるようになるのがそんなに前時代的かね?栓抜きついたアイフォンケースドゾー

https://www.amazon.co.jp/ZVE-iPhone6-ケースiPhone6s-ライター-栓抜き-カメラ三脚機能付きケース-アイフォン6s/dp/B013Q4VRAI

”あと入力のものに関してもタッチパネル式では何のどこにする操作が何を意味するのかサービスによっては全く逆のデザインであることも珍しくないしそういった揺らぎは無意識意識的ストレスユーザに与え続けてる。”

そもそも一つ一つアプリ作ってる会社うから当たり前ですよね。OSだって使い勝手も随分変わりましたし。

キーに関しては戻るボタンを作ればそれを推せば戻るという機能限定されるためいちいちソフトによってマニュアル確認する必要もなければ押す箇所が毎回違う必要性もない”

一つ一つボタン作るの?今どれだけの入力値や種類がある?キーボードマウス入力できる入力値が全て?ジェット機のコックピット並みにボタンだらけにするのがあなたのいう先進的で効率的なのかな?ジェット機のコックピットだって今はデジタルで切り替えられるものになってるよ。スマホ入力ってキーボードだけじゃなくて音声入力タッチペンでの入力ジャイロ使った三次元入力だってあるよね。全部キーボードOK?

結局、見えている範囲しか話をしていないのは君なんだよ。君は見たいものだけ見て、それで自分が一番正しいと思ってる。食堂に行ったらずらっと並んだ見たことも食べたこともないお惣菜目の前にしてポカーンとしてたら、御盆だけ渡されて「自分の好きなもの食べな」って言われてるのに店員に「お前んところのベスト定食を俺に提供しろ」って喚いてるおっさんと同じかな。もしくは「全部のせで」って頼んでる人かな。

君がどこの誰でなんの開発をしてるのかわかりませんけど、いいものができるようお祈りしています

anond:20171128115217

うーん、やっぱり君の理解度が足りないのか俺の話し方が悪いかだ

俺はスマホの方が優れてるのを認めつつも進化方向性として入力・出力を切り分けたモバイル存在するべきだったという話を最初からしていた

用途に合わせて色々用意しなきゃいけなくなった時点で道具としての価値付属品が増えるほど落ちるよ

必要な物だけ使えばいいだろというけどその人にとって必要な物っていうのは必需品であってスマホキーボード必要になった時点で

ガラケースマホ比較ガラケースマホキーボード評価になる

面積を馬鹿にするという観点なら圧倒的にスマホ不利になるけど

まあ、やっぱりこれ以上話をしても意味なかったな

可能性の話をするときに現状の見えている範囲しか話ができない人間は成長性もないし開拓も開発もないとつくづく思うよ

きっとスマホが出る前はガラケーがどんだけ素晴らしいのか力説してたんだろうけどー

スマホってむしろ一体型を諦めて敗北宣言した後に選択肢を与えるように見せかけてユーザ負担無限に増やしてるだけじゃん

やってることはゲームDLC商法と同じで最初から機能つけなくても不満なくニコニコ現金払いしてくれる馬鹿を増やす仕組み

からiPhoneブランディングに力入れたんだよ

頭の悪いコレクターに信じ込ませやすくするため

せいぜいカメラの性能とか通信速度やバッテリーで張り合うくらいで虚しさしかない

画面がでかくなった!とか。

はあ。

そうすか。

周辺機器全込みの金を最初からだすから全部機能ついてるスマホ出してくれよ

必要になるたびに買うとか繋げるとか持ち運ぶという二度手間を何度も強要するのが効率的先進的?

それ間抜けとどう違うんだ

栓抜きでさえ多機能で揃えてきてるのに栓抜き以下の設計思想スマホだよ

 

あと入力のものに関してもタッチパネル式では何のどこにする操作が何を意味するのか

サービスによっては全く逆のデザインであることも珍しくないしそういった揺らぎは無意識意識的ストレスユーザに与え続けてる

キーに関しては戻るボタンを作ればそれを推せば戻るという機能限定されるため

いちいちソフトによってマニュアル確認する必要もなければ押す箇所が毎回違う必要性もない

まあ、君は信仰してるわけだな今のスマホ

2017-11-07

anond:20171107115221

まあ普通に考えたらそうだわな

可変機能を持つ世代MSマクロスとやっと同等なんだから

MSミノフスキー粒子散布下で真価を発揮するから

設計思想からして違い、どうやっても対等な立場でもないけど

ミノフスキー粒子散布下→MS有利

ミノフスキー粒子なし→マクロス有利

2017-10-29

はてなハードウェアエンジニアが少ない件

エンジニア一言で言っても星の数ほどのジャンルがあるが、その中でも代表的なのはハードウェアエンジニアソフトウェアエンジニアだと思う。

まりに広範囲区分けだが、敢えて定義はしないでおく。

さて、自分新米ハードウェアエンジニアで、ソフトウェア趣味人間である

はてなにはソフトウェア記事(及びブックマーク)が多く、日曜プログラマ自分にとって大変有益である

大抵の悩みは検索をかければ解決するし、自分では想像し得ないようなユニーク記事もあり毎日が発見連続だ。

特にユーザコメントが好きで、皆の関心が伺える“はてなはいくら見ていても飽きない。

ただ、ハードウェアに関する記事が少ないことが残念でならない。

エンジニアカテゴリを覗いても、ハードウェアに関する記事が上がっていることは稀である

たまにラズパイIoTキットに関する記事があるだけで、デジタル回路におけるインピーダンスシミュレーションとか、高速差動信号の放射電波対策とか、そういった踏み込んだ記事はほぼ無いと言っていい。

当然アナログ回路のGNDレイアウトに関する記事は皆無だし、ソフトウェア寄りと言えるRTLコーディング記事さえ見当たらない。

ハードウェアエンジニア守秘義務なのだろうか?

・・・・・・

・・・

ソフトウェア技術日進月歩

イマイチ盛り上がらないハードウェア業界比較して、ソフトウェア業界の隆盛は火を見るよりも明らかである

コーディング環境、つまりPCがあればその先には広大な世界が広がっている。

語弊を恐れず言うが、アイディア次第ではその日のうちにスターダムにのし上がることも可能かもしれない。

当然、アマチュアを含めたエンジニア人口を見るとソフトウェアエンジニア人口は突出しているだろう。

なので記事数の多さは人間性質に依るものではなく、単純に人口の違いだろう。

ハードウェア面白いのに、何故手を出す人が少ないのだろうか。

ロボコンなんか見ていると、胸に込み上がるものがあると思う。

ハードウェア自然界の物理法則の下で成り立っているため、主に電磁気学電気回路電子回路勉強するだけでいくらでも応用が効く。

言うなればソフトウェアよりも参入障壁は低いはずで、高校物理で習ってきたこである程度の回路が組める。

FPGAなりでハードウェアアクセラレータ自作し始めると計算機科学知識必要になるが、ここはむしろソフトウェアエンジニアの方が得意な領域だ。

・・・・・・

・・・

こんなことを言っておいて、自分ハードウェアを始めたのは社会人になってからである

学部修士時代の専攻は材料物理学だったため、工学とは全く縁が無かった。

ここから自分ハードウェアの道に進んだきっかけを書こうと思う。

新人研修の昼休み、あるフラクタル図形を高速描画するハードウェア記事が目に留まった。

当時の自分にはその偉大さが理解できなかったが、2年もの間寝食を忘れて没頭できるその世界に心が惹かれた。

人生を変えることになる出会いだった。2012年の春である

早速オームの法則から復習し、使ったこともない半田ごてやテスターを買ってきて4bit CPU製作に取り掛かった。

ALU(算術論理演算回路)以外はディスクリート部品で組んだため、デバッグ含めて完成までに6ヶ月も掛かってしまった。

その後FPGA存在を知り、8bit CPUを載せてみた。

機械語勉強し、命令デコーダ設計して1年後、自分の考えたプログラム動作したときは嬉しかった。

上述した記事追体験しているようで、仕事を忘れて没頭していた。

続いてFPGAマイコン+汎用ROMの組み合わせでプリント基板を起こしてみた。

目的は勿論、あるフラクタル図形の高速描画である

ここでレベル変換やリセットシーケンスなど、デジタル回路の基礎を身に付けることができた。

基板レイアウトの考え方は専門的であるものWEB簡単情報が手に入ったし、殆ど電磁気学世界なので理不尽ものは無かった。

苦労したのがマイコンプログラムだった。

機械語論理的な手順をコード化するだけだったが、組み込みC言語はそのルールが難解だった。

言い方は悪いかもしれないが、人間の考えたルールだろうと理不尽に思える理論もその設計思想を調べもせず暗記で済ましていた。

メモリリークが発生した場合ハードウェアのように現象を観察して仮説検証することが難しく、ダンプなどのデバッグ手法も知らなかった。

そんなとき、社内でセキュアプログラミングなる研修があったため同期と潜り込んでみた。

参加資格の無い自分が参加できたのは、配線だらけの汚い自作CPU子供のような目で見てくれた上司の厚意だった。

そして1年後、自分モニタの中で鮮やかに描画されるフラクタル図形を眺めていた。

上述した研修講師に1年間師事し、半ばマンツーマン計算機科学を教えて頂いていた。

大学講師の方だったため、C言語ルールではなく命令処理系としての働き、ハードウェアとの関連を核にして叩き込んでもらった。

・・・・・・

・・・

紆余曲折を経て、ハードウェアエンジニアとして働いている。

こういう部署では多少なりともソフトウェアができると光るものである

ただ組み込みC言語以外はサッパリのため、日々独学の毎日だった。

そこで出会ったのが“はてな”だった。

そこにある記事はどれも眩しくて、「ある疑問の解決法」を検索するだけでは決して出会えない珠玉記事の宝庫だった。

きっとハードウェア世界にも、自分では想像し得ないような発見があるはずだ。

それこそあのフラクタル図形のような驚きが。

・・・・・・

・・・

今は仕事の傍ら、奇しくもプロになってしまった自分義務として細々とハードウェア記事を書いている。

残念ながら驚くような技術ではないが、誰かにとって小さな発見があれば嬉しい。

これを読んだ人がハードウェアに興味を持ってくれたらと思う。

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