はてなキーワード: SWIFTとは
https://survey.stackoverflow.co/2018#technology
https://survey.stackoverflow.co/2020#technology
https://survey.stackoverflow.co/2022/#technology
https://survey.stackoverflow.co/2024/technology
- | 2018 | 2020 | 2022 | 2024 |
JS | 69.8 | 67.7 | 65.36 | 62.3 |
Python | 38.8 | 44.1 | 48.07 | 51 |
TS | 17.4 | 25.4 | 34.83 | 38.5 |
JAVA | 45.3 | 40.2 | 33.27 | 30.3 |
C# | 34.4 | 31.4 | 27.98 | 27.1 |
C++ | 25.4 | 23.9 | 22.55 | 23 |
C言語 | 23.0 | 21.8 | 19.27 | 20.3 |
PHP | 30.7 | 26.2 | 20.87 | 18.2 |
Go | 7.1 | 8.8 | 11.15 | 13.5 |
Rust | - | 5.1 | 9.32 | 12.6 |
kotlin | 4.5 | 7.8 | 9.16 | 9.4 |
Ruby | 10.1 | 7.1 | 6.05 | 5.2 |
Swift | 8.1 | 5.9 | 4.91 | 4.7 |
Scala | 4.4 | 3.6 | 2.59 | 2.6 |
変化がわかりやすいように2年ごとにした
JAVAって永遠に人気なのかと思ったけど、10年後人気言語と言えなくなってるかも
PHPはそろそろ厳しい
C#も地味に衰退
去年から稼働している現場で、以前からあったReact Nativeの面倒を見ているんだがまあこれがひどい出来なんだ。
jQuery時代に見かけたようなコードをやたら見かけたので思わず懐かしくなってしまった。
リファクタリングしようとしたけど直す範囲が広すぎてアプリを壊しかねなかったので、早々に諦めてだましだまし保守をしていた。
そんな中今年に入ってアプリのリニューアルの話が出てきた。React Native捨ててSwift/KotlinやらFlutterに書き換えるとかそういうのではなく、デザインの刷新といくつかの機能改修。
このままだとアプリが更に魔窟化するので、マネージャーに色々相談したところいくつかの事実がわかった。
ということだった。
結局現状のまま進めるわけにはいかず、要件定義の傍らリファクタリング作業をしている。
そういう経緯もあったので、リファクタリングとテストの工数も積んだ上で見積もりだしてもらってる。
「レガシーアーキテクチャをモダンアーキテクチャに刷新」なんてよく聞く話しだけど、
実態は「長年の増改築とだましだましのリフォームが限界になってきたので新築で建て替えます」何だと思う。
最近は「Vue.jsからRemixにマイグレーション」なんて見かけるけど、悪いのはVue.jsじゃなくて禄に設計しないでコード書いてるエンジニアと、
リファクタリングには予算でないけどマイグレーションなら予算取れるという悪しき風習。
年がら年中フロントエンド刷新しているような会社は地雷なので行かないほうがいい。
例えばInstagramやFacebookに近しいものとか。
インフラはできればAWSで作る。Firebase(NoSQL)で作ってAWS(RDS)に移行するなどできればもはや完璧。
フロントはWebでもモバイルでもいいけど、WebであればReact, Vue、モバイルであればFlutter, Swiftを使う。
WebであればSSL化、モバイルであればApp Storeに掲載までは必須。実績として見れられるものがあることが大事。
ここまでが最短で半年くらい。
あとはこれを材料にフリーランスを探せば良い。やったことないけどココナラを挟むという人もいるらしい。
これだけの実績があれば月単価50万なら案件ゴロゴロ見つかる。
いきなり60(年720)は見つからなくとも、50スタートで経験積めば60はすぐにいく。
なんだかんだ人が足りないというところは山ほどある。
横だが、そういうのって「はてな」の見出しを見てるだけで目に飛び込んで来ないか? JavaScript関係だけでもこの20年間にどれだけ変化があったことか。他にもweb系で使われている言語の盛衰やフレームワークの入れ替わりとかだけでも凄いじゃん。今や Perl それ何? 状態だろうし、GoにSwiftにRustにCotlinにScalaにWebAssemblyにと次から次へと新しいものが出て来てるしバージョンアップでの変化もあるし。C/C++だけでもちゃんとついて行くには勉強し続けないといけないし。開発手法もアジャイルだスクラムだなんだと喧しいし、デバッグの手法関連もそうだし。今やデバッグドリブンで自動化でとかが当たり前っぽいし。
2月10日に"Web3"を痛烈に批判する Web3って流石にヤバくないか? という記事が話題になっていたので拝読した。
過激な内容に加えて、非常にセンスとユーモアに溢れる文章で楽しく読ませて頂いた。
さらに、そのアンサー記事として2月12日に出ていた Re: Web3って流石にヤバくないか? という記事も読ませて頂いた。
こちらの方も業界に非常に精通されていて非常に的を得た反論が展開されていた。
両記事を読む中で、少し補足したい部分がいくつかあったため、遅ればせながらアンサー記事に対して自分の考えを補足する形で書いていこうと思う。
https://anond.hatelabo.jp/20230212193550
本当の意味で、最も理想的に分散されているのはビットコインだが、ビットコインは本体も関連プロジェクトも、エンジニアに対する金払いは悪い。というかほぼボランティア。精力的に活動しているのはビットコイン長者の老人だけで、将来にわたっての開発の持続性がない。そもそも若い世代は育つはずがない。ビットコインはその大半が採掘されていて、これから人の一生分かけて、残り僅かな枚数のコインがちびちび採掘されて、すでに固定化されたマイナーに払われ続けるだけだ。自分が一枚も持ってないビットコインのために誰が働こうと思うのか。
ビットコインのコア開発者になろうとする人は確かにいないかもですね。だってもう開発する追加機能自体がないんだもの。ビットコインのコア開発者に今からなりたいって人がいたら、私だって止めますね。
広く捉えるとビットコイン含めたL1チェーンの開発の持続可能性に課題があるという話と理解した。
開発者のインセンティブという意味では、L1チェーンが利用され、Profitableである限りは通貨の価値が上昇するため、イーサリアムなどの多くのチェーンでは財団がGrant (開発支援金) を出し続けることができると思う。
チェーンがProfitableである基準については『The first profitable blockchain』( https://newsletter.banklesshq.com/p/the-first-profitable-blockchain )が詳しい。
ビットコインは機能追加を積極的にしないという哲学があり、そもそも開発するものがないという話は確かにあるが、仮に外部環境が大きく変わった場合にそれに適応することができるかどうかは開発エコシステムにかかっているとは思う。
ビットコインは財団にあたる団体が明確に存在しないので少し弱い気はするが、"ビットコイン長者の老人"たちが自身の保有するBTCの価値を高める・維持するためにGrantに相当する寄付を行う経済的インセンティブはあるため、それに期待。
つまり、そんなに価格が上がることはなくて、その分採掘の難易度が下がらないとマイナーの収支が取れなくなるんだが、そんなことしてたらいつか危ないんじゃないか?51%攻撃リスクだっけか。「ビットコインはハッキングされたことがありましぇぇん(キリッ」とかいつまで言ってられるだろうね?
マイナーの収支と1ビットコインの当たりの価格に関しては相関がないですね。マイナーの収支はTransaction Feeによって賄われるので、1ビットコインの採掘報酬がゼロになったとしても運用は回る設計になってます。慈善事業ではなくビジネスなので電気代やハードウェア費の採算が取れないTransaction Feeを指定したトランザクションは取り込みませんので、1ビットコインあたりの価値が1億円円だろうが1万円だろうが、Transaction Feeは現実的な値に落ち着くのが経済の原理です。51%攻撃が未来永劫受けないのはありえない話なので、過疎化したら攻撃可能になるのは間違いないです。まぁ過疎化した時点で二束三文だと思いますけど。
究極的には「ビットコインというシステムが提供する価値」「イーサリアムというシステムが提供する価値」の需要がどのくらいあるかが全て。
もし誰も使わなくなったら終わるというのはその通り。
ただし、これはどんなサービスでも同じで、別にWeb3に限った話ではない。
結局そこで流行っているスマートコントラクトは、チンパンホイホイのポンジーファイナンスくらいなんだが。... 規制されない金融を可能にしたら、クソみたいなスキームでクソみたいなマネーゲーム環境が無限に湧いて出てきて、誰が一番多くドルに換金できるかの競争が起こって盛り上がり、なぜかそれがイノベーションとか言われているだけなんだ。規制ないところのアナーキー金融道なんてものは、産業革命の時代以降ずっと人類は経験してて、そのときどきでクソって結論になっててな。そりゃこの世界、規制ばかりでつまらないクソな世界だけど、これでもマシなクソを選んだんだよ。
大前提、投資家保護を完全に無視した無法地帯であるDefiとそこでのマネーゲームはポンジと批判されて然るべき。
その上で第一原理的な発想で「Defiは規制に対応していけば良い」そして「規制に対応したとしても価値がある」と考える。
仮にDefiがしっかりと規制された未来を考えてみると、その金融システムには大きく3つの価値があると思う。
これは金融DXやFintechがやろうとしていること、その理想形であり、彼らは既存システムをボトムアップで改善しているが、それに対してDefiは理想的なシステムをデジタルスクラッチで作ってしまって後から規制に対応させるというトップダウンの方法を取っていると整理できる。
第二に「グローバルに規格が統一されており、オープンでパーミッションレスな金融システム」となる。
SWIFTですら各国のシステムのツギハギであり、非常に複雑なシステムになってしまっているという課題感があると聞くし、国際送金、国際証券決済などが全くの追加コストなくシームレスに行える状態というのは未だ実現されていないと理解している。
さらに、オープンさにより金融システムと接続されているシステムを作成するコストが低くなる。
これは既存金融がOpen API、Open Bankingで目指している方向と同じとも言える。
第三に「分散的に動作しており改ざんできないという特性から監査が楽になる」
仮にボトムアップの金融DXが完成したとしても、それを運営する団体が存在した場合はそこに対するトラストが発生する=運営団体が資産を隠したり、改ざんしたりする可能性を捨てきれないため、分散化した金融システムに比べると監査コストが高くなる。
上記3つの価値により、「ファイナンスのコストが大きく下がる」ことが期待される。
そしてそれによって、これまではファイナンスできなかったような小さな主体でもファイナンスにアクセスすることが出来るようになる。
もちろん規制に対応する上で、システムとしても現状から大きく改善される必要はあると思うので、この未来が確実に来るとは言えないが、この未来を信じて仕事をすることに価値はあると思う。
お待たせしましたどーもDAOだお。あのな、DAOなんてものは、株の代わりにトークンで投票するだけで、別に社会的に新しいことはなんもないんだお。でも惹かれる気持ち分かるんだお。なんかイノベーティブに聞こえるし、ウォレットで投票して手軽にガバナンス参加とか新鮮だし良いよね。たまに空からお金落ちてくるし。ディスコードみたいなカッコいいとこには老人もいないし。リリースするソースコードに投票したり、ワクワクするよね。でも、それ、ブロックチェーンいらなくね?ウォレットなんか使いこなせるやつ世の中にどれくらいいると思ってるの?日本人の6人に1人は偏差値40以下なんだが?ニーモニック?100年早いわ。エアドロ?手元にお金ないけどお金配りおじさんになりたい人のためのアレすか!?。ディスコード?運営企業頼みやん?非中央集権どうしたん?。リリースされるコードの投票?デプロイするエンジニアたちは信用しないといけないやん。数人が結託するだけで、みんなから集めたDAO資金からお金無限ちゅーちゅー列車が出発できちゃうプロジェクトばかりなんだが。DAOなんて、自律もしてなければ、分散もしてない、ただの組織なんだお。なんだろう、雰囲気でweb3するのやめてもらっていいすか?
これも同意見。なんでみんなDiscordでやってるのかマジで謎。情報が分散しすぎてて情報収集辛いんじゃ〜。
DAOに関しては定義の整理をするべきと考える。
まずそのDAOは本当にDAOかどうか、つまりDecentralizedかどうかを考える。
まずプロトコルレイヤーであるL1・L2チェーンはDAOであると言えると思う。
世界中の誰もがNodeを動作させることができ、コンセンサスメカニズムによりDecentralizedに動作しているのは間違いない。
誰でもforkすることができる。
一方でアプリケーションレイヤーのDAOは「リリースされるコードの投票?デプロイするエンジニアたちは信用しないといけないやん。」と批判されている通り、そもそもDecentralizedではない = DAOではないものが多い。
DAOであるためには「分散投票の結果として起こる事象やアクションがフルオンチェーンで分散的に動作している」必要がある。
つまり、機能追加の投票を行い、それをコアチームのエンジニアがDeployしている場合などはDAOとはいえない。
一方で、Decentralizedである=分散投票の結果として起こる事象やアクションがフルオンチェーンで分散的に動作しているものの例としては「tokenの保有者がオンチェーンで投票活動をし、ファンドの資金を投票結果で決まった特定のアドレスに送金するロジックまでがオンチェーンで動作している」ような分散ファンドのアプリケーションなどが挙げられる。
この整理をすると批判記事にあるようなDAOはそもそもDAOではないということになるため、批判に同意である。
更に踏み込んで、本当にDecentralizedなDAOは少しは存在するとして、DAOであることで生み出している価値は何かを考える。
プロトコルレイヤーの場合、Decentralizedであることのメリットは「Assetsの管理を自分以外の誰にもされない」金融システムであることだ。
もし仮に利用者が分散マキシじゃないとしても、(中央集権的な金融システムと比較してUXなどその他の条件が同じとすると) 資産の管理を他人に依存して良いことは1つもないので、これには価値があると言えるだろう。
アプリケーションレイヤーの場合は、アプリによるが上記で例に出した分散ファンドでいうと、投資ファンドを誰か特定の人物または数人のグループに依存せずに分散的に運用できるという価値はあるといえる。
これによってファンドマネージャーが資金を持ち逃げするなどのリスクはなくせるというメリットはある。
それにどれだけの需要があるかは未知数だが、少なくとも無価値ではない。
そしてNFT氏とかブロックチェーンゲーム氏。お前らは金の匂いを消せ。お前らが呼び寄せたどんな陽キャでも明るくできないくらい、界隈が冷めてるの気づかないのか?それに、サ終しても、ブロックチェーン上にあなたの資産は残るとかいう嘘やめろ。お前らはブロックチェーンが無くならないといつから錯覚していたんだ?
サービス終了してもブロックチェーンに記録は残りづづけるので嘘ではない。ブロックチェーンがなくならないとは言ってないので。嘘じゃないけど真実ではないこの言い方は私も好きじゃないが。草コインのチェーンはそのうちひっそりと消えるだろうな。
金の匂いの批判に関しては、まずTokenomicsと相性が悪いゲームもGamefiとして提供されていることが原因だと考える。
ゲームの本質的なユーザーバリューは「プレイする面白さ」であるのに、Gamefi・Tokenomicsを導入することにより、Tokenの値段の上下を気にしなくてはいけない、最悪の場合にはゲームを遊んでいたらなぜか損をするという状態になってしまう。
Tokenにより、ゲームの本質的なバリューが毀損されてしまうのでむしろTokenomicsは入れないほうが良い場合が多い。
一方で、Tokenomicsを入れる相性の良いゲームとしては「そもそも賭博性のある」ゲームがある。
賭博性そのものがゲームの面白さというタイプのゲームであればTokenomicsによって面白さが増すことは考えられる。
ただし、賭博は本来しっかりとした規制があるので、規制と折り合いをつけていく必要はもちろんある。
一方で、Gamefiではない=TokenomicsのないBlockchain Gameもあり、これには可能性があると思う。
それらは「運営が終わっても資産が残る」というここで批判されている価値よりも、Composabilityによるバリューが大きい。
Composabilityとはゲーム同士が連携したり、あるゲームの上に別のゲームを拡張して作ったりすることが、誰でもできるという価値である。
これは既存ゲームの世界で考えてもマインクラフトでも行われているし、オセロというゲームを元にしてソシャゲに拡張したものや、麻雀を拡張したゲームなどが多く作られてきている。
あるゲームのバックエンドのロジックであるスマートコントラクトが誰でもアクセス可能なことで、そのゲームの別のClientを作成したり、別のゲーム性を付け加えたりできるイメージである。
拡張できるものの範囲が広がることでより面白いゲームが生まれる可能性はあると思う。
僅かな流動性の中で買い支えて成り立つトークン価格と、膨れ上がったトークン発行量の掛け算で、ユニコーンな時価総額が成り立っているんだ。その縁で辛うじて立っているおびただしいプロジェクト...
言及なし
付け加えると、海外プロジェクトを中心とするWeb3界隈であたかも画期的な発明のように言われている「Stakingさせることによって売り圧を減らす」というトークノミクス手法は、要は顧客である資産の保有者が資産を売れないようにして流動性=売り圧を減らすことで価格を維持するという運営目線の話で、株式会社でいうと「節税手法」みたいなものと理解している。
プロジェクト運営のハックとしては理解できるが、新たな価値を生んでいるイノベーションでもなんでもなく、声高に言うようなことではないと考えている。
間違っている部分や別の考え方などがあればコメント頂けると大変嬉しいです。
"I sprang upon the swift ship in the form of a dolphin, pray to me as Apollo Delphinius; also the altar itself shall be called Delphinius and overlooked forever." - Homer
っていうあれね。
訳すと
私はイルカの姿で快速船にとびかかった。デルフォイのアポロンとしての私に祈れ。祭壇もデルフィニウスとよばれ、永遠に見渡されるであろう。
って感じかな。
ホメーロスのどんなところに出ているか、「イーリアス」にも「オデュッセイア」にもなかった気がしたので、英語版のウィキペディアの「Delphi」で調べたら、「ホメーロス風讃歌」の「アポローン讃歌」からの引用みたい
邦訳はあるっぽい。
で、wiktionaryで語源を調べるとデルフォイΔελφοίの語源はデルフスδελφύς (delphús)子宮の複数形かららしくて、ドルフィンと語源は同じだね。
swiftじゃね(ハナホジ)
↑を書いた元増田ですが、VBの話から派生した話で、やたらコマンドライン(以下CLI)を使った開発に否定的な人間がいて閉口した件。
そりゃ一口に開発と言っても色々なので、本当に統合開発環境(以下IDE)だけで開発するケースもあるのは、こっちも知ってるんだよ。
だから学習者の中で「何をやりたいか」が既に決まっているなら、CLIを全く触らずプログラミングを学ぶケースもアリということなのだろう。
1つ目は、そもそも「プログラムって何?」というレベルの人が「何をやりたいか」なんて決まっているわけがないので、最初から「何をやるか」を決めてかかるのはナンセンスという話。
むしろどういう開発に進んでもいいように、「等号は代入を意味する」辺りから始まって、どんなプログラミングでも基礎の基礎になる、データ構造とアルゴリズムを意識させることに集中させたい。
そのためには難易度低めで比較的潰しが効く言語を、できるだけシンプルな手順で作業できる開発環境で学べる方がいい。
そしたらPythonの実行環境とそこそこ以上の機能を持つテキストエディタを入れて、コマンドプロンプトとかPowerShellとかのCLIから"Helllo, world"が取っ掛かりだと思うわけ。
もしLinuxの環境が用意できるなら同じことをLinuxでも試してもらって、プラットフォームに依存しない開発の入り口くらいを知っておければベター。
いずれにせよ何かを実行する方法が1つではないという重要な知見は、できれば基礎のうちに知ってもらいたいことの1つだし、それはWindowsとLinuxとかCLIとIDEという対比がうってつけかなーと。
ちなみにIDEは、Pythonによる手続き型プログラミングに慣れた後のタイミングで学べばいいと思う。
そこまで行ったら変数の型や、クラスとオブジェクトとかの難しい話をGo言語で学んでおくことで、現場で使われているJava、C#、swiftへの移行もスムーズになりそうだし。
ちなみに「初心者コース」の最後、もし可能ならRustでポインタとメモリの話の触りくらいを体験してもらえると、組み込みに進む際のハードルが少しは下がるんじゃないかな。
もう1つは、いくら現場によってはIDEだけで開発する現実があっても、CLIを使った開発がどういうものかくらい、プログラマにとっては知ってて当たり前じゃねーの?という話。
もちろん「プログラマが何を知ってて当たり前なのか」は、時代の移り変わりとともにどんどん変わる。
大昔ならおそらく機械語とかが必須だっただろうけど、今なら機械語よりはHTMLを読めるほうが遥かに重要なわけで。
あと、UNIX系OSをパーティションごとに主要なディレクトリを分割してインストールしていた時代であれば、edエディタの使い方は必須だったと聞く。
(/binに入るエディタがedのみだったため、もし使えないとシステムクラッシュして/以外マウントできなくなったときに詰む)
でも今やそんなの完全に過去の話どころか、viとemacsの論争ですら多分古い方の問題になるだろう。
そういう過去の諸々も踏まえるとCLIが未来永劫、プログラマにとって常識的なナレッジだとは自分も思っていない。
でも今はまだ、プログラマを名乗るならCLIからコンパイルだ実行だくらいの基礎は知ってて当然だと思うんだが。
それは即戦力を求めすぎ。