「BUILDER」を含む日記

■anond:20240910092816

GPT-builder の knowledge-dataとして参照させてください。全体を一括処理するような場合を除けば 10万token あったとしても問題ないはず。API で公式サービスに対抗するのは大変なのでゴニョゴニョした方が楽かもしれないですね。

Permalink | 記事への反応(0) | 14:01

ツイートシェア

■ITはつまらなくなったけど、料理、イラスト、漫画、楽器、作曲とかは寧ろ楽しくなったんだよな

例えば、俺、CoffeeScriptが嫌いだったんだけど、なんで嫌いかっていうとRubyが嫌いだからなんだけど（諸説あります

でも、頑張ってCoffeeScriptゴリゴリ書いてた人たちっていると思うんだよね

自分はTypeScript登場時からずっとTypeScriptなんだよね

だって、アンダース・ヘルスバーグだよ？

バーグハンバーグバーグじゃないよ？

あの、DelphiとかTurbo PascalとかC++ BuilderとかC#の原作者だよ？

しかし、なんだ、こうやって陳腐化していくことがどれほど多いことか、IT関係は

これが理系で機械工学関係だったら、流体力学とか材料工学が陳腐化するなんてないよね？

普遍的な知識を、技術を大学で習ってるはずなんだよね

だから、大学で習う情報工学だとしたら、やっぱりできるだけ普遍的なことを習ってるはずなんだよ

でも、ITはyak shavingが多いよね

本質的な知識を得るために、WindowsやLinux上の環境で学ばなければならないわけで、

落ち着いて情報工学の勉強をするために、Windowsの余計な情報を表示するウィジェットの閉じ方を学ばなければならなかったりする、馬鹿げてるよね

そう考えると、料理、絵、音楽、みんな普遍的なものの集まりだよね

料理の四面体なんてあるけど、煮る焼く炒める蒸すどれも不変な過程だよね

調理器具だって、フライパンや鍋が日進月歩に進化して、以前のバージョンが使えない、なんて買い替え需要を促すための嫌がらせをメーカーがしたりもしない

絵だって、証券用インクとペンだとしても、液晶ペンタブレットだとしても、筋肉の知識とか、パースの知識とか、不変だよね、永遠に変わらないものだよね

まあ、流行の絵柄とかは変わるけど、そういう流行に流されないのも大事だよね

個性がない、ってことは、誰かが絵を見て、これは～さんの絵だ、って気づかれないってことだから、商品価値がなくなっちゃうよね

ピカソじゃないけど、敢えて意図して個性的に描くの大事だよね

音楽理論も変わらない、楽器の弾き方も変わらない、正直、ギターなんてどこのメーカー買ったって同じようなものなんだけど、

同じエレキギターを何本も持ってる人っているよね、お金持ちだよね、自分はチューニングがそれぞれ違うギター複数本持ってるけど、それはチューニングのためなんだよね

話を戻すと、ITクソつまらなくなった、の元の文章にもTypeScriptでクソアプリ書いてたときが楽しかったみたいな話があったけど、

俺がMacOSX 10.2だったかで作ったアプリは、現在のMacではまったく動かないからね

Xcodeでrebuildしても怪しいんじゃないかな

その点、Windowsは凄いよね、後方互換性が凄い…

だったんだけど、今のWindowsはAppleみたいになっちゃったよね、足切り、足切り、Windows 10は動くけど、11は動かないマシンが大量発生

全部Ubuntuにでもするのかね？困っちゃうね

アルゴリズムとか数学は不変だよね

不変なことを勉強した方がいい、流行に流されるな

でも、なんか実装しようとすると、途端に流行の～をマスターしなければならなくなるよね、IT系の嫌なところだよね

もう何かに振り回される人生を終わりにしたいんだよね

Permalink | 記事への反応(1) | 18:50

ツイートシェア

■【追記あり】RTA in JAPAN Summer 2024で解説が面白いおすすめ動画（クリアまで1時間以内編）

ポケットモンスター赤緑のソロプレイに注目が集まっているRiJだが、もう一つの見所が、今何が起こっていて、何が超絶技巧なのかを視聴者に教えてくれる解説である。

現在、YouTubeに上がっているものの中から、「クリアまで1時間以内」「解説が面白さを引き立てている」という視点でピックアップした。

なお、これからアップされるものの中でも、紹介したいもの（例えば、「wallprime」など）があるので、できれば追記したい。

（トラバの助言を受けて、YouTubeからtwitchのリンクに変更した。コメントから当時の臨場感が伝わってくると思う。一方、YouTubeの方は走者さんや解説さんがコメントを書いていることもあるし、視聴者もコメントを残せるので、こちらも見てほしい）

（追記：速報版の6つに、ラストまでの4つを加えて完成。リンクとして張れるのは9本までのようなので、1本は頭を削った）

RITE

https://www.twitch.tv/videos/2221332904

走者兼解説。

フレーム単位で9段階のジャンプを使い分け、精密な十字キー操作を行いながら、淡々と各面のポイントを述べていく解説がクール。

「ちょっと（難しい）」の定義とは？。

Lonely Mountains: Downhill

https://www.twitch.tv/videos/2221428977

キャラが死ぬたびに、こらえきれずに吹き出す解説さんにつられ、会場も爆笑につぐ爆笑。

人が死んでんねんで！

SkateBIRD

https://www.twitch.tv/videos/2222178941

解説さんがいなければ、プレイの意味が全く分からなかったゲーム。

最後まで丁寧に解説してくれる。

序盤の「ﾓﾝﾁ、ﾓﾝﾁﾓﾝﾁﾓﾝﾁｽｸﾘｰﾑﾓﾝﾁﾓﾝﾁﾓﾝﾁ!!」はぜひ聞いてほしい。

ソロモンの鍵

https://www.twitch.tv/videos/2222216364

走者と解説さんによる「ショートコント：RTA」。

超絶テクニックを「うまいー」「はいうまいー」「うまいねー」と妙なテンションで流すのがシュール。

「次の面は癒やし」からの仕事猫案件、グダるけれど、グダった後のトークも面白い。

サイレントドラゴン

https://www.twitch.tv/videos/2222276074

走者兼解説。サイレントドラゴン愛が強すぎて笑うしかない。

途中でRTAの趣旨を逸脱してワンコインクリアに集中したり、

一方で、すぐにダウンするためコンボを決めさせてくれない敵に「勝手に倒れてどうするんだ！RTAだぞお前！」と説教したりとやりたい放題。

カービィのきらきらきっず

https://www.twitch.tv/videos/2223151102

解説さんが常にポジティブ。

時に無茶ぶりをし、時に圧をかけるのもたまらない。

「世界記録って、速いですからね」は今大会で1、2を争う名言。

（追記）

ミスタードリラーエース ふしぎなパクテリア

https://www.twitch.tv/videos/2223819722

走者兼解説。ギリギリのシチュエーションを率直に言語化してくれるので、自分がプレイしているような気分になる。

多分視聴者全員、酸欠状態だったと思う。

「（天井から石が降ってきて）あっヤバ（瞬間に生存ルートを見つけて）くない…。ヤバくないですよ」と強がるのも面白い。

よく分からないジョークセンスも最高。

wallprime

https://www.twitch.tv/videos/2223820910

壁に表示された4桁までの数字を、ひたすら素因数分解していくゲーム。

走者の頭はどうかしているとしか思えない超速「素数パンチ」に加え、

解説さんの「どうやって素因数分解をしているのか…ですが、基本は覚えます（7割は覚えている）」との発言が加わり、

ポケモン赤緑に続く「ホラー枠」に認定。

SimCity

https://www.twitch.tv/videos/2223897031

プレイ時間のうち3分の2ぐらいは、ただ待つだけなのだが、そこを解説に定評あるワイズさんが、

ゲームプレイや、ゲーム周りの情報だけでなく、人間批評、社会批評も含めて解説していく。

これは解説を見るための動画といっていい。

LEGO® Builder's Journey

tps://www.twitch.tv/videos/2224602471

正確にレゴブロックを組み上げていく走者と、それに合わせてよどみなくストーリーを展開していく解説さんのタッグ。

RTAと知らなければ、Eテレの番組かな？と思うほどの完成度。

時折挟まれるメタな解説も、クスリとさせてくれる。

さて、最後になるが、実は当初（大会が終了する前）、10本を紹介するつもりであり、10本目はスーパーマリオ64目隠しプレイで締めるつもりでいた。

走者のBubziaさんは、昨年夏のRiJに目隠しゼルダBotWの目隠しプレイを披露し、目隠しときメモとともに社会（の一部）を震撼させたので、覚えている方も多いだろう。

スーパーマリオ64でも、RiJ 2021 Winterで目隠し・スター70枚というレギュレーションを走りきっており、解説はそのときと同じ宇佐見まさむねさん。

世界記録はBubzia氏当人の持つ13分19秒。

鉄板の組み合わせである。

が、結論から言うと、RTAに失敗した。

Bubziaさんにとって、とても納得のいくプレイではないことは明らかであり、おすすめに挙げることは躊躇せざるを得なかった。

しかし、宇佐見さんの、走者の操作だけでなく心情とも完全に同期し、Bubziaさんが失敗した場面で、各トライアルの何が失敗の要因かを正確に言語化した解説は、

個人的にはある種の美しさを感じた。

おすすめはできないが、一度見てほしいとも思う。

Permalink | 記事への反応(7) | 11:43

ツイートシェア

■anond:20240606150120

ビジュアル系の時代なんだな

最近の女子小学生も好きな男性像がホストっぽい顔立ちだったりするみたいだし…

俺もMicrosoft Visual C++ 6ぐらいから使ってるビジュアル系だからモテるはずなんだけどな…😟

（でもDelphiとかC++ Builderの方がビジュアル系だよな

Permalink | 記事への反応(1) | 20:48

ツイートシェア

■anond:20231227120052

一応世界Top10くらいのテックでエンジニアやってたけど

一つもやったことないなw

データストラクチャとアルゴリズムは割とガッツリ手を動かしてやった

O(N)はこんなの当たり前だろと思ったら世の中考えてないエンジニアが山ほどいた

Builderだののパターンはまあ見ればわかるっしょ

DDDだのTDDだののデザインパターンは大体Wiki

OOPは英語のJavaのチュートリアル

Web ServiceはSunの本社で計3週間くらい

勉強は仕事中にやる方針

残業はしない方針

こんな感じ

Permalink | 記事への反応(3) | 12:19

ツイートシェア

■

きっと今頃すいすい増田はGPT Builderを使ってGPT4Turbo水野曜子ちゃんを作っているにちがいない

期待している

Permalink | 記事への反応(0) | 12:38

ツイートシェア

■

AWS Skill Builderいつまでメンテナンスしてるの

Permalink | 記事への反応(0) | 18:58

ツイートシェア

■

<META name="GENERATOR" content="IBM WebSphere Studio Homepage Builder Version 10.0.0.0 for Windows">

http://7n3gks.o.oo7.jp/bus/newpage10.htm

ほーむぺーじびるだー10だ

Permalink | 記事への反応(0) | 22:52

ツイートシェア

■はっきり言っておくが、Visual Studioは

まったくビジュアルじゃない！

未だに！

Borland C++ Builderの方が未だにビジュアルに思える！

ビジュアル系！

LUNA SEAとか？

ビジュアル系の人がVisual Studioはイケてない

でも、ビジュアル系の人がvimならどうだろうか？

Permalink | 記事への反応(0) | 17:17

ツイートシェア

■ボディービルダーVSガンダムビルダー

VS C++ Builder

Permalink | 記事への反応(0) | 15:27

ツイートシェア

■ボーランド、ウクライナにC++ BuilderとDelphi、200ライセンス以上を供与

Microsolt Visual C++なんてクソだべさ

Permalink | 記事への反応(0) | 20:41

ツイートシェア

■anond:20210527102211

xcodeのInterface Builderの.nibだっけ？

RADで生成されるものは大きくてもuntouchableだし、

DelphiとかC++ Builderなんかで書く量はかなり少なかった記憶がある

Permalink | 記事への反応(1) | 10:24

ツイートシェア

■anond:20201124155603

Xcodeは自分も駄目だった

なんでだろう

これまで改良はされてきたし、最新のは知らんのだけど、

プロジェクトの設定とかとりあえず必要最低限だけ表示すればいいのにドバーッと全部表示してしまってて、

しかも結局はコマンドラインのオプションをGUIでチマチマ書くような感じになってしまってて、

これIDEの意味あんの？みたいになるわけだけど、Xcodeを使わないと基本的にMacやiOSのアプリを開発できない縛りもあるわけで、

あと、うろ覚えだけど昔たしかInteface Builderのnibファイルとかバイナリだったんじゃなかったかな

バージョン管理しづらい、差分が分からない、うっかりマウスを滑らせてどこか変更してしまっても分からない、

NeXTはそれでも良かったのかもしれないけど、なんだかなあと思って、できるだけ使いたくなくなる不思議なIDE

Borland C++ BuilderとかDelphiは楽しかったのになあ

Permalink | 記事への反応(0) | 16:03

ツイートシェア

■自分のプレイしたゲームを晒す

この間、増田でプレイしたゲームを晒してたのを見て面白かったから自分のも晒してみる。

おすすめがあったら教えてくれ。

以下プレイ時間順

↓

Rocket League

記録時間: 790 時間

Sid Meier's Civilization V

記録時間: 672 時間

Cities: Skylines

記録時間: 635 時間

RimWorld

記録時間: 521 時間

Terraria

記録時間: 377 時間

METAL GEAR SOLID V: THE PHANTOM PAIN

記録時間: 350 時間

Factorio

記録時間: 330 時間

Fallout 4

記録時間: 268 時間

Assassin's Creed Odyssey

記録時間: 254 時間

Heat Signature

記録時間: 149 時間

7 Days to Die

記録時間: 132 時間

Assassin's Creed IV Black Flag

記録時間: 127 時間

Sniper Elite 4

記録時間: 114 時間

Assassin's Creed Origins

記録時間: 109 時間

Reassembly

記録時間: 97 時間

HITMAN™

記録時間: 91 時間

METAL GEAR SOLID V: GROUND ZEROES

記録時間: 80 時間

The Witcher 3: Wild Hunt

記録時間: 67 時間

Kerbal Space Program

記録時間: 61 時間

Watch_Dogs 2

Stellaris

記録時間: 58 時間

Tom Clancy's Ghost Recon® Wildlands

記録時間: 55 時間

Tom Clancy's Splinter Cell Blacklist

記録時間: 32 時間

Dungeon Warfare

Far Cry 4

記録時間: 31 時間

HITMAN™ 2

記録時間: 27 時間

Dead Rising 3

記録時間: 25 時間

Graveyard Keeper

記録時間: 20.0 時間

The Elder Scrolls V: Skyrim

記録時間: 18.6 時間

The Escapists 2

記録時間: 17.1 時間

Starbound

記録時間: 15.7 時間

INSIDE

記録時間: 15.3 時間

Stardew Valley

RPG Maker MV

記録時間: 13.8 時間

Dishonored

記録時間: 13.5 時間

Borderlands 2

記録時間: 12.7 時間

Project Zomboid

記録時間: 12.6 時間

Kingdom: Classic

記録時間: 12.5 時間

Papers, Please

記録時間: 12.0 時間

BioShock

記録時間: 10.3 時間

Batman: Arkham City GOTY

記録時間: 8.8 時間

BioShock Infinite

記録時間: 8.7 時間

Universe Sandbox

記録時間: 8.6 時間

Portal 2

No Man's Sky

記録時間: 8.5 時間

Avorion

記録時間: 5.6 時間

Starbound - Unstable

記録時間: 5.5 時間

Superflight

DARK SOULS™ II

記録時間: 5.2 時間

LIMBO

Saints Row IV

記録時間: 4.9 時間

How to Survive

記録時間: 4.4 時間

Hearts of Iron IV

記録時間: 4.2 時間

Quantum Break

記録時間: 4.1 時間

Undertale

記録時間: 3.5 時間

GRIS

記録時間: 3.4 時間

Age of Empires® III: Complete Collection

Gunpoint

ペルソナ4 ザ・ゴールデン

記録時間: 3.1 時間

FTL: Faster Than Light

記録時間: 2.9 時間

Creeper World 3: Arc Eternal

記録時間: 2.3 時間

片道勇者

Garry's Mod

記録時間: 2.2 時間

The Talos Principle

Mini Metro

記録時間: 2.0 時間

Life is Strange™

記録時間: 1.6 時間

Return of the Obra Dinn

記録時間: 1.2 時間

STEINS;GATE

記録時間: 0.9 時間

This War of Mine

Rebel Galaxy

記録時間: 0.8 時間

Game Builder

Valiant Hearts: The Great War™ / Soldats Inconnus : Mémoires de la Grande Guerre™

記録時間: 0.7 時間

DiRT Rally

Invisible, Inc.

記録時間: 0.5 時間

UNDEFEATED

記録時間: 0.4 時間

ISLANDERS

Sins of a Solar Empire: Rebellion

記録時間: 0.3 時間

Wallpaper Engine

記録時間: 0.2 時間

The Witness

Age of Empires II (2013)

記録時間: 0.1 時間

The Flood

VRChat

Grow Home

Metal Gear Solid Legacy

Age of Empires II (2013): The Forgotten

Alan Wake

Assassin's Creed III Remastered

Audio Party Pack (オーディオ・パーティパック)

BioShock 2

BioShock 2 Remastered

BioShock Remastered

Borderlands 2: Headhunter 1: Bloody Harvest

Borderlands 2: Headhunter 2: Wattle Gobbler

Borderlands 2: Headhunter 3: Mercenary Day

Borderlands 2: Headhunter 4: Wedding Day Massacre

Borderlands 2: Headhunter 5: Son of Crawmerax

Borderlands: The Pre-Sequel

BROKE PROTOCOL: Online City RPG

Cities: Skylines - After Dark

Cities: Skylines - Green Cities

Cities: Skylines - Mass Transit

Cities: Skylines - Snowfall

Civilization V - Scrambled Continents Map Pack

Company of Heroes 2

Crusader Kings II

Crusader Kings II: African Portraits

Crusader Kings II: South Indian Portraits 5 Year Anniversary Gift

Cuisine Royale

Dead Rising 3 DLC1

Dead Rising 3 DLC2

Dead Rising 3 DLC3

Dead Rising 3 DLC4

Door Kickers

Evolvation

For Honor

For Honor - Public Test

Fortified

Hacknet

Half-Life 2

Half-Life 2: Lost Coast

Her Story

Insurgency

Killing Floor

Killing Floor Mod: Defence Alliance 2

Layers of Fear

Left 4 Dead 2

Monaco

Murderous Pursuits

Overlord

PAYDAY 2

Pinball FX3

Prismata

Regions Of Ruin

Satellite Reign

Shadow Warrior

Sid Meier's Civilization III: Complete

Sid Meier's Civilization V: Brave New World

Spec Ops: The Line

Starpoint Gemini 2

Stellaris: Original Game Soundtrack

Streamline

The Escapists 2 - Dungeons and Duct Tape

The Flame in the Flood

The LEGO® NINJAGO® Movie Video Game

The Talos Principle - Bonus Content

The Talos Principle - Prototype

The Talos Principle - Soundtrack

The Talos Principle: Road To Gehenna

The Witcher 2: Assassins of Kings Enhanced Edition

The Witcher: Enhanced Edition

Tomb Raider

Viscera Cleanup Detail: Shadow Warrior

Yume Nikki

ZACH-LIKE

片道勇者プラス

追記

・Kenshiはニコニコ動画で見て面白そうだと思い、プレイしたんだけどとても重くてまともにプレイできなかった思い出。

・プレイ時間はSteamが管理してくれていてアクティビティから確認できるんだ。Steamがわからなかったら調べてね。

Permalink | 記事への反応(2) | 17:32

ツイートシェア

■今年流行りそうなおすすめYouTubeチャンネル

・出版の裏側

現役の編集者が出版業界の裏側を暴露するというチャンネル

テンポよく歯に衣着せぬ物言いで内情を詳らかにしていく

チャンネルの性質上ピー音や伏せ字も沢山あるがそれでも十分面白い

編集者志望や作家志望からのアドバイスにも定期的に応じている

漫画家やライトノベル作家志望の人間からも多くの質問が寄せられるが

「まずはネットで腕試ししてから送ってこい」というのが最近の定番の返しになっている

ゲストはいつも匿名形式での参加となっているためコメント欄では推理大会が開かれる

・脱マッチョ宣言

元ボディビルダーの男性が女装に挑戦するチャンネル

女装に関してズブの素人だった人間が徐々にレベルアップしていく様子を楽しめる

最初はただ単にユニクロなどで買ってきたものを着るだけだったが

コメント欄の女性や女装家のアドバイスを参考にしながら

わずか一年の間にガチで女性にしか見えないレベルにまで到達してしまう

元が中性的な顔立ちということを差し引いても凄かった

YouTubeでの収益をすべて寄付しているらしい

・BLOCKS HOUSE BUILDER

デンマークで建築家をやっているLEGOガチ勢のチャンネル

建築家のスキルを生かしてLEGOで家を組み立てるというチャレンジをしている

ただ単にガワだけを再現するのではなく機能性の高い本格的な住宅を建築中

LEGOブロックの意外な断熱性能の高さを見るにつけ

自分の家の断熱対策をLEGOでやってみようかと思ってしまう

”Primitive Technology”を連想するという人がコメント欄にもちらほらいる

・巷のデバッガー

ゲーム会社でデバッガーをやっている大学生のチャンネル

街なかを歩いているときに見かけた様々なものを紹介するという動画を上げているが

見たものをあたかも”現実のバグ”であるかのように紹介するというユニークな手法をとっている

加えて豊富なゲーム知識と絡めて説明することでよりいっそうのおかしみを漂わせている

コメント欄では「これがゲーム脳か……」というような文言が定番化している

海外ファンからは映画マトリックスになぞらえてモーフィアスとあだ名されている

・ミニヨンズ

改造ミニ四駆に心血を注ぐレッツ＆ゴー世代のチャンネル

金と暇を持て余したアラサー兄弟がひたすらミニ四駆の限界に挑み続けている

個人的には動力源改造シリーズが結構気に入っている

回を増すごとにヤバさがインフレしているところも懐かしの少年漫画っぽくていい

初心者には「ミニ四駆にウルトラダッシュモーター○個搭載してみた」をオススメする

不定期にやっている「ミニ四駆とビーダマンをかけ合わせようシリーズ」も見て欲しい

Permalink | 記事への反応(0) | 22:34

ツイートシェア

■anond:20190624140926

✕
if(肉に火が通っている)火を止める;
else if (3分たった)火を止める;

○
火が通った肉 = 炒める(肉, 3 * 60);

OOPだとbuilderパターンがうまいことハマる気がする

Permalink | 記事への反応(0) | 11:58

ツイートシェア

■

<META name="GENERATOR" content="IBM WebSphere Homepage Builder V6.0.0 for Windows">

これを見るとお腹いっぱいになっちゃう

しかも

<META http-equiv="Content-Type" content="text/html; charset=Shift_JIS">

とかな

Permalink | 記事への反応(0) | 16:27

ツイートシェア

■[はてな統計]補足)はてなブックマークホットエントリ入りしたドメイン2005年〜2008年

http://anond.hatelabo.jp/20170220005414 の1年間隔のデータ。

前エントリの5年毎のデータじゃ思い出を振り返るには分解能が足りない気がしたので1年間隔で補足します。興味ない人にはスパムエントリ並にうざいのだろうから申し訳ないけど、その当時を見てたらただの数字の羅列には見えないのですよ。近々はてブシステムに大幅な改修が入るらしいから今やっとかないと来月も同じように見られるとは限らないしね。

はてなブックマークホットエントリ入りしたドメイン 2005年〜2008年

(※カッコ内は回数)

毎年3月の全ホットエントリを http://b.hatena.ne.jp/hotentry/20050215 から取得。タイルレイアウトで取得したので1日49件×31日で月間合計1519件弱のデータを基にしている。重複はuniqで取り除いてある。

Permalink | 記事への反応(3) | 18:56

ツイートシェア

■http://anond.hatelabo.jp/20160730155428

悪い、昼間っからビール飲みだしたから、もうよくわからん。

それをそのままってのが意味がよくわからんけど、

newしてから渡せば良いと思うよ。

いちいちクラスに分ける理由は、こういう感じで、クラス内の変数にアクセスすれば、画面事の表示とかが簡単に出来る的な？

EventHogeクラス（クリックした時のイベントを定義するクラス）

　　　　　　// Javaの書き方しらん、インターフェースを実装することを定義したい

　　　　　　public class EventHoge : View.OnClickListener {

　　　　　　　　//画面事の名称

　　　　　　　　public string ViewName = "";

　　　　　　　　// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい

　　　　　　　　public void View.OnClickListener.onClick(View v) {

　　　　　　　　　　　　// 元増田のサンプルそのまま ーー＞

　　　　　　　　　　　　AlertDialog.Builder dlg;

　　　　　　　　　　　　dlg = new AlertDialog.Builder(MainActivity.this);

　　　　　　　　　　　　dlg.setTitle("画面の名前：" + ViewName); // 画面名称が表示されるイメージ

　　　　　　　　　　　　dlg.setMessage("Hello, サンプル!");

　　　　　　　　　　　　dlg.show();

　　　　　　　　　　　　//＜ーー

　　　　　　　}

　　　　　}

MainHogeクラス（画面の初期化を行い、どのボタンにどのイベントを仕込むかを決めるクラス）

　　　　//　Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい

　　　　public class MainHoge {

　　　　　　　　//　そのメソッド

　　　　　　　　public void Main() {

　　　　　　　　　　　　//ボタン実装のサンプル

　　　　　　　　　　　　final Button button = new Button(this);

　　　　　　　　　　　　button.setText("ダイアログの表示");

　　　　　　　　　　　　View.OnClickListener ocl = new EventHoge();

　　　　　　　　　　　　ocl.ViewName = "画面その一";

　　　　　　　　　　　　button.setOnClickListener(ocl);

　　　　　　　　}

　　　　}

こんな感じにすれば、画面が二つあって、

その画面の名称を表示するようなボタンを、二つメソッドをコピペして作らなくていい的な？

もうぶっちゃけ、元増田が何を悩んでるのか、ようわからんわ。

サンプルは、出来るだけとっちらかさないよう、匿名クラスとか使って、サンプルで紹介したいところ「だけ」を書くんだよね。

だから、そのサンプルがどういう意味かをちゃんと読み取って、自分ならこう書くとか、こう書けるか？ とかを考えてこそ勉強だと思うよ？

今回のレイだと「View.OnClickListener」っていうインターフェイスを実装したクラスを、setOnClickListenerすればいいってことさえわかれば、

匿名クラス？（っていうのかな？ ちょっと用語はよくしらん、クラス定義を使い回さず、その場だけのクラス定義を書く書き方）とかを使わずに、

どういうふうに応用ができるか？ とか頑張れ！

頑張れ！

頑張れ！

はああああああ。

おれはビールを飲む！

Permalink | 記事への反応(0) | 16:21

ツイートシェア

■http://anond.hatelabo.jp/20160730125112

うーん？

いや、なんか、通じてないな。

もうちょいサンプル詳しく書くから、サンプルのどこがわからないか言ってくれ。

EventHogeクラス（クリックした時のイベントを定義するクラス）

　　　　　　// Javaの書き方しらん、インターフェースを実装することを定義したい

　　　　　　public class EventHoge : View.OnClickListener {

　　　　　　　　// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい

　　　　　　　　public void View.OnClickListener.onClick(View v) {

　　　　　　　　　　　　// 元増田のサンプルそのまま ーー＞

　　　　　　　　　　　　AlertDialog.Builder dlg;

　　　　　　　　　　　　dlg = new AlertDialog.Builder(MainActivity.this);

　　　　　　　　　　　　dlg.setTitle("サンプル");

　　　　　　　　　　　　dlg.setMessage("Hello, サンプル!");

　　　　　　　　　　　　dlg.show();

　　　　　　　　　　　　//＜ーー

　　　　　　　}

　　　　　}

MainHogeクラス（画面の初期化を行い、どのボタンにどのイベントを仕込むかを決めるクラス）

　　　　//　Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい

　　　　public class MainHoge {

　　　　　　　　//　そのメソッド

　　　　　　　　public void Main() {

　　　　　　　　　　　　//ボタン実装のサンプル

　　　　　　　　　　　　final Button button = new Button(this);

　　　　　　　　　　　　button.setText("ダイアログの表示");

　　　　　　　　　　　　button.setOnClickListener(new EventHoge());

　　　　　　　　}

　　　　}

こうやって、クラス分けて書けば、外とか中とか、全く関係なくなるじゃん。

元増田のサンプルだと、メインの中でインターフェースを実装したクラスの実装を書いてるから、中とか外とかがあるんじゃないのか？

自分でクラスとして定義して、そっちで実装すれば、メインは紐づけるだけでよくなって、仮引数？の中で実装しなくてもすむじゃん。

Permalink | 記事への反応(2) | 13:08

ツイートシェア

■http://anond.hatelabo.jp/20160730090832

よくわからん。

中が嫌なら外でかきゃいいじゃん。

javaもAndroidもしらんから適当だけど。

　　　　　　// Javaの書き方しらん、インターフェースを実装することを定義したい

　　　　　　public class Hoge : View.OnClickListener {

　　　　　　　　// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい

　　　　　　　　public void View.OnClickListener.onClick(View v) {

　　　　　　　　　　　　// 元増田のサンプルそのまま ーー＞

　　　　　　　　　　　　AlertDialog.Builder dlg;

　　　　　　　　　　　　dlg = new AlertDialog.Builder(MainActivity.this);

　　　　　　　　　　　　dlg.setTitle("サンプル");

　　　　　　　　　　　　dlg.setMessage("Hello, サンプル!");

　　　　　　　　　　　　dlg.show();

　　　　　　　　　　　　//＜ーー

　　　　　　　}

　　　　　}

// メインスレッド的なところ

//ボタン実装のサンプル

final Button button = new Button(this);

　　　　button.setText("ダイアログの表示");

　　　　button.setOnClickListener(new Hoge());

こう書けば、中で書かなくて良い気がするけど、駄目なの？

なんか、インターフェースだから引数の中ってのが意味わからん。

どう関係してるの？

Permalink | 記事への反応(1) | 12:05

ツイートシェア

■オブジェクト指向 v.s. 関数型プログラミング

近年、関数型プログラミングの重要性はいろんなところで叫ばれています。

Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。

Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。

プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。

関数型プログラミングへの注目度は高まってきています。

おそらく、みなさんは既にオブジェクト指向が何か、を知っています。

でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。

実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、

関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。

この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。

この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。

みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。

ふたつのアプローチの比較

オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。

関数型プログラミング的アプローチは、汎用部品でなんとかする。

オブジェクト指向的アプローチ

Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。

また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。

継承やクラスは、オブジェクト指向の必須条件ではありません。

オブジェクト指向の本質とは、何でしょうか。

その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。

最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。

これらの処理をまとめたら、わかりやすいですよね？

対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。

識別することとイコールで比較できることは、とても良く似ています。

イコールによる比較は、オブジェクト指向では鬼門であることが知られています。

PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。

また名前をつけて識別する対象は、フワフワしていてはいけません。

たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。

ところで彼が昇格したときに何が起こるでしょうか。

新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。

なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。

関数型プログラミング的アプローチ

一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。

小さな関数を、集めて撚り合わせて、新しい関数を作る。

関数自体をリストなどのデータ構造に詰めることもよく行われます。

実は、関数型プログラミングというのは本質を表していません。

その真の名は、"値指向プログラミング"です。

関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。

あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。

変数という概念は必要ありません。

変数に適用する処理を作りあげることが、とても簡単だからです。

四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。

値をイコール比較することも、なんのそのです。

誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。

関数型プログラミングの利点

読みやすい・理解しやすい

関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。

• ファンクタ: "コンテナ"一般を表すもの。
• モナド・コモナド: "手続き"一般を表すもの。
• アロー: "回路"一般を表すもの。
• トラバーサブル: 木やリストのような、各所を周って要素に変更を加えられるデータ構造一般。
• フォルダブル: 再帰的に"畳み込めるデータ構造"一般を表すもの。

このような構造をインターフェイスとして、様々なライブラリが組まれているので、

たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、

パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。

理解しやすいこと。これが関数型プログラミングの大きな利点です。

追記:

また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。

Haskellな人がPythonにトライした結果 - Togetterまとめ

書きやすい

関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。

よく誤解されていますが、これはウソです。

スクラッチでプログラムするのは、非常に手軽です。

＞＞ map (*2) [1,2,3]
[2,4,6]

邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。

関数型プログラミングのコードは、潔癖かつ濃密です。

たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。

上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。

関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。

多くのバグは、コンパイルエラーとして検出されます。

また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。

たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。

やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。

統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。

そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。

いつ関数型プログラミングか

以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。

• "人工物"クラスが増えてきた。
• Builderパターン、Strategyパターン、Commandパターン、Interpreterパターンが増えてきた。
• DI注入のとき、コンストラクタ注入にするか、セッター注入にするか、いつも迷う。

一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。

そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。

それこそが関数型プログラミング的アプローチです。

オブジェクト指向の利点

初心者にとっては読みやすい・理解しやすい

特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。

関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。

そのため、初学者にとってはハードルが高いのです。

扱う対象があまり複雑でない時は、書きやすい

オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。

そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。

関数型プログラミングの得意分野はなにか

数値計算

遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。

分数を扱うことができます。虚数もです。

関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。

テキスト処理

手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。

関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、

彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。

並行処理

手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。

関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。

さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。

Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。

C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。

レシピ

もう少し簡単な例をあげます。

あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。

料理のレシピは、"手続き"ですよね？たとえば、カレー。

1. まず玉ねぎを炒める。

2. 飴色になったら、肉を加えて炒める。

3. 野菜を加える。

4. 水を加えて煮る。

5. スパイスを加える。

しかしあなたはこの手続きを関数として表現できるでしょうか。

…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。

これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。

そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。

あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。

このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。

オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。

野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...

こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。

カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。

C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。

GUI

iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。

このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。

これをオブジェクト指向で実現しようとすると、

1. 三つの異なるボタンを同じ位置に置くか

2. 同じボタンが三つの異なる機能を持つか

という下らない問題にぶつかります。

一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。

「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」

この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。

しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。

近年、PCのディスプレイの大きさは、頭打ちになってきました。

画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。

これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。

したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、

関数型プログラミングの力を頼るしか無いでしょう。

はじめよう、関数型プログラミング

つまり…

Haskell さいこうなのおおおおおおおおおおおおおおおおおお!!　おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ

1. google:すごいHaskellたのしく学ぼう を注文する。

2. Download Haskell を自分のPCに導入する。

3. コンソールにghciと入力して、対話型コンソールを立ち上げる。

4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。

take 4 $ map (*2) [1..]

5. ステップ1で買った教科書を読んで、学ぶ。

追記:

いかがでしたか？

ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。

オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。

一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。

この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。

Permalink | 記事への反応(8) | 01:08

ツイートシェア

■http://anond.hatelabo.jp/20110824113709

FlashDevelopを知らない時点でダウト

Flash製作環境が高いじゃん。HTML5の方が投資コストが格段に低い。割安。

知ってるけどSDKで開発するぐらいだったらFlex Builder買ったほうが労力的に安いわ。

矛盾してね？

つまりHTML5よりFlash使ったほうが安いということだろ。

Permalink | 記事への反応(1) | 12:08

ツイートシェア

■http://anond.hatelabo.jp/20110824101045

Flex SDKを知らない時点でダウト

知ってるけどSDKで開発するぐらいだったらFlex Builder買ったほうが労力的に安いわ。

Permalink | 記事への反応(1) | 11:37

ツイートシェア

■http://anond.hatelabo.jp/20100327151237

http://www.eonet.ne.jp/~senyou-mondai/

なんか今時このホームページビルダー丸出し感が返って新鮮な雰囲気を感じるなぁと思っていたら

<META name="GENERATOR" content="IBM WebSphere Studio Homepage Builder Version 8.0.2.0 for Windows"&gt;

パネエ……。

Permalink | 記事への反応(1) | 15:23

ツイートシェア