タグ

プログラミングに関するkazutoxのブックマーク (257)

  • JavaScriptにセミコロンは入れるのか?入れないのか? - Qiita

    結論 どちらでもいい セミコロン付けても付けなくても落とし穴はある ESLintを利用することで落とし穴を検知できる 私はセミコロンつけない派 自動セミコロン挿入とは 自動セミコロン挿入(automatic semicolon insertion) この仕組みのおかげでセミコロンを使わなくてもコードを書くことができ、コンパイラが行末を察してセミコロンを挿入してくれる 自動セミコロン挿入のしくみはECMAScriptで規定されており、自動セミコロン挿入はJavaScriptエンジン間で可搬性がある 自動セミコロン挿入には落とし穴があり、ルールを理解しておく必要がある 第1のルール:セミコロンが挿入されるのは、"}"トークンの前か、改行の後か、プログラムの末尾だけ

    JavaScriptにセミコロンは入れるのか?入れないのか? - Qiita
  • 次期C標準 (C23) の内容が固まったらしい

    C23については最近のC言語と、次期C標準(C23)でも軽く紹介しました。 今回、C23入りする内容が大体固まったようなので改めて紹介します。 この記事を書いている時点での最新の公開されたWorking Draftは N2912 N3047 N3054 N3096です。ただし、C2y向けの最初のドラフトN3220もあり、そちらの方が実際の内容に近いかもしれません。 内容については会議参加者の投稿も参考にしています: https://twitter.com/rcs/status/1550526425211584512 C23 now finalized! : C_Programming というわけで、C23に入る主な機能はこちらです: C23に入る主な機能 POSIXの機能の取り込み: strdup, strndup, memccpy, gmtime_r, localtime_r C++の機

    次期C標準 (C23) の内容が固まったらしい
  • 『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』を読めばアーキテクトになれるのだろうか - Magnolia Tech

    ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 作者:Mark Richards,Neal FordオライリージャパンAmazon とても良いだ!アーキテクチャのパターンは体系的に整理されているし、アーキテクチャを議論する上で、共通の語彙となり得る用語を解説している(コンウェイの法則や、凝集度など)。 後半は、リスクや、チームビルディング、交渉術まで多岐に渡るトピックを網羅している。 必要なことは全部書いてある...けれど、なんとなく初めてPMBOKを読んだときに抱いた感想...読み始めてからすぐに「果たしてこのに書かれている通りの考え方に沿って振る舞えばアーキテクトになれるのか?」という気持ちになりはじめたところで1章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。 ソフトウェアアーキテクチャはトレード

    『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』を読めばアーキテクトになれるのだろうか - Magnolia Tech
  • プログラミングの最初の壁は逐次実行 #projava - きしだのHatena

    プログラミングの入門書で、変数だとかfor文なんかは丁寧に例えなどを使って説明されていることが多いのですけど、逐次実行はほとんど説明されていることがありません。 入門書を書く人にとって、逐次実行は自明であって説明が必要なものではないという認識があると思います。 プログラムに慣れた人にとって、プログラムが上から順に実行されるというのは当たり前で学習が必要なことには思えないと思います。 「見たままやん」 となるのではないかと。 けど、実際には上から順に動くというのがよくわからないようです。 「あ、プログラムって上から順番に実行されるんですね、わかってなかった」 と言われたことがあります。そういうふうに言ってくれる人がいるということは、言わないけどわかってなかったという人が何倍もいるはずです。 通常の文章というのは、基的には一定の状態を仮定して書かれていて、前部と後部で表す状態が違うということ

    プログラミングの最初の壁は逐次実行 #projava - きしだのHatena
  • No RailsConf

    2021 was an incredible year for Ruby on Rails. We started it off still celebrating the third major version of Ruby, and left it with the accomplishment of the seventh major version of Rails. Together, these releases sparked a renewed enthusiasm for building modern web applications with Ruby on Rails, unlike anything I can recall since the late oughts. The moment was finally right, and we were righ

    No RailsConf
    kazutox
    kazutox 2022/03/04
    DHHがRailsConfのキーノートスピーチから外されたらしい
  • JavaScriptのレガシー挙動を定めたAnnex Bをひたすら読む記事

    ECMAScript Annex Bおよび関連する仕様を読みます。 おことわり 言うまでもありませんが、ここで説明されている機能は使わないようにしましょう。 筆者がJavaScriptを書き始めたのは2005年頃で、その後2010年代は実質的な空白期間でした。そのため記事に含まれる歴史的背景の説明は、2005年頃の筆者が学んだ内容に加えて、当時の資料を遡って調査した結果に基づいて記載されています。できる限り信頼性の高い情報を見つけた上で記述するよう心がけましたが、当時常識だった知識の欠落等により不正確な記述になっている部分があるかもしれません。もし誤り等があったら指摘いただけると嬉しいです。 現在のzennでは <sub></sub> や <ins></ins> は描画されていませんが、心の目で下付き文字や下線装飾に読み替えてください。 ECMAScript Annex B とは ECM

    JavaScriptのレガシー挙動を定めたAnnex Bをひたすら読む記事
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
    kazutox
    kazutox 2022/01/10
    2018年の記事、読んだけどブクマしてなかった
  • プロと読み解く Ruby 3.1 NEWS - クックパッド開発者ブログ

    技術部の笹田(ko1)と遠藤(mame)です。クックパッドRuby (MRI: Matz Ruby Implementation、いわゆる ruby コマンド) の開発をしています。お金をもらって Ruby を開発しているのでプロの Ruby コミッタです。 日 12/25 に、ついに Ruby 3.1.0 がリリースされました(Ruby 3.1.0 リリース )。今年も Ruby 3.1 の NEWS.md ファイルの解説をします。NEWS ファイルとは何か、は以前の記事を見てください。 プロと読み解く Ruby 2.6 NEWS ファイル - クックパッド開発者ブログ プロと読み解くRuby 2.7 NEWS - クックパッド開発者ブログ プロと読み解くRuby 3.0 NEWS - クックパッド開発者ブログ 記事は新機能を解説することもさることながら、変更が入った背景や苦労な

    プロと読み解く Ruby 3.1 NEWS - クックパッド開発者ブログ
  • 個人的なアプリケーション設計のバイブル3選 - Runner in the High

    自分が格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション

    個人的なアプリケーション設計のバイブル3選 - Runner in the High
  • Go言語が好きな理由

    はじめに 私はGoが好きなので、disられている場面に遭遇すると心が痛みます。残念ながらプログラミング言語について深く語れるほどの知識や経験は持ち合わせていないため、世界が平和になることを祈るくらいしかできません。 (元ネタ)Go言語を嫌う6個の理由 - さめたコーヒー それはそれとして、Goが好きな理由を語る人はあまり見かけない気がします。この記事ではGoが好きな理由を視覚に障害のあるユーザーの視点から語ります。読み終えたところで得るものは何もありませんし、長いので覚悟して読んでください。 あなたは誰? 4年ほど業務でサーバーサイドのGoを書いています。また、業務で使いはじめる前から趣味Goに触れていました。そのため無意識の内にひいきしているかもしれません。ただし、流行っているからといって理由もなくGoを勧めたりはしません。 視覚障害ならではのコーディング事情 Goが好きな理由と深く関

    Go言語が好きな理由
  • Go言語を嫌う6個の理由 - さめたコーヒー

    ある仕事でそれまでRubyで書かれていたサーバーサイドをGo言語ですべて書き直すことになって、それまでRubyのコードを書いていた僕はそのままGo言語を書くことになった。その仕事そのものはお客様(僕は外部委託のエンジニアとして参画していた)との関係も良好で素晴らしい仕事をさせてもらうことができたと思っているが、Go言語だけは好きになれなかった。 はじめは流行っている言語だから何か素晴らしい魅力があるのではないかと期待していた。しかし書き始めるうちにどうも自分には合わないなと思うようになり、2年ほど書いて案件の契約が終わる頃にはGo言語でサーバーサイドを書くことは危険だとさえ思うようになった。 あれから数年がたちますますGo言語の案件は増えている。サーバーサイドを書く選択肢としてGo言語を選択する会社も増えている。しかし当にそれでいいのか?ただ流行っているからという理由だけで選択するにはあ

    Go言語を嫌う6個の理由 - さめたコーヒー
  • JavaScript クイズ解説: NaN === NaN の結果はどうなる?

    先日、このようなツイートを書きました。 久しぶりの JavaScript クイズ。 JavaScript において NaN === NaN の結果は次のうちどれになるでしょうか? — Takuo Kihira (@tkihira) September 7, 2021 答えは 4 の「状況によって上記以外もありうる」です。でも、2 や 3 を選んだ方も、もはや正解だといって差し支えないと思います。 解説が長くなったので、ブログ記事にまとめました。 そもそも NaN とは NaN は “Not a Number” を意味する数値です。数値なのに「Not a Number」というのは違和感があるかもしれませんが、数値表現することが出来ない状態を保持するために便宜的に用意された数値、というようなものです。 NaN は、浮動小数点演算において数値では表現出来ない計算をしようとすると登場します。例えば

  • Rails 7 will have three great answers to JavaScript in 2021+

    September 6, 2021 Rails 7 will have three great answers to JavaScript in 2021+ Rails has been unapologetically full stack since the beginning. We've continuously sought to include ever-more default answers to all the major infrastructure questions posed by modern web development. From talking to a database, to sending and receiving emails, to connecting web sockets, to rendering HTML, to integrati

    Rails 7 will have three great answers to JavaScript in 2021+
  • 実はDDDってしっくりこないんです - タオルケット体操

    DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット(といいつつほぼ忘れかけている)なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用(採用できているとは言っていない)しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい

    実はDDDってしっくりこないんです - タオルケット体操
    kazutox
    kazutox 2021/09/04
    “過去何度もDDDでプロジェクトが爆死するのをみたり” いったいどこにいるとそんなに何度も見れるものなのか
  • Modern web apps without JavaScript bundling or transpiling

    August 12, 2021 Modern web apps without JavaScript bundling or transpiling I didn't much care for vanilla JavaScript prior to ES6. Through all of the 2000s, I chased different approaches to avoid writing too much of it. First there was RJS (Ruby-to-JavaScript). Then there was CoffeeScript. Both transpiling approaches that turned more enjoyable-to-write source code into the kind of JavaScript that

    Modern web apps without JavaScript bundling or transpiling
  • 最近のC言語と、次期C標準(C23)

    C言語といえば古い言語なイメージですが、その重要性はまだまだ落ちていません(多分)。重要な言語だからこそ、今もひっそりと進化を続けています。この記事では、そんなC言語の最近の動向を紹介します。 まずはC言語の前世紀の標準であるC99、現行の標準であるC11/C17を振り返り、その後に未来の標準であるC23に触れます。 C99 C99では色々追加されました。ここでは一部のみの紹介とします。 _Bool _Complex C++の std::complex とメモリ上での互換性がある(C++11以降)。 可変長配列(VLA) 可変長引数マクロ 浮動小数点数の強化 十六進表記 筆者による関連記事:浮動小数点数の16進表記 fma 筆者による関連記事:FMA (fused multiply-add) の話 #pragma STDC FENV_ACCESS, #pragma STDC CX_LIMI

    最近のC言語と、次期C標準(C23)
  • Message Passing - はなしをふったりふられたり

    Message Passing は N 人のプログラマ (jmuk, karino, kzys, morrita, shinh) が話をふったりふられたりしつつプログラミングやソフトウェア開発の雑談をするブログです。意見は書き手個人の見解です。どうみても。 Message Passing is licensed under CC-NC-SA. It has a feed and is hosted by a GitHub organization. Uses this for the OG image.

    Message Passing - はなしをふったりふられたり
  • ナビつき! つくってわかる はじめてゲームプログラミング | Nintendo Switch | 任天堂

    ゲームをあそぶのは楽しいけれど、 つくるのも楽しい。 誰でもつくってあそべる、 ゲームプログラミングを体験してみませんか?

    ナビつき! つくってわかる はじめてゲームプログラミング | Nintendo Switch | 任天堂
  • レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ

    技術部の外村(@hokaccha)です。今回はクックパッドのウェブサイトのフロントエンドNext.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.jsGraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが

    レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
    kazutox
    kazutox 2021/02/04
    2020年12月
  • PHP - The Wrong Way

    概要 PHPプログラミングの世界では、ある一定のトレンドが「モダンPHP」として、一部の人によって (彼らの書籍やウェブサイト上で) 強烈に広められ、他のアプローチは、遅れていたり、愚かだったり、あるいは単に間違いだとみなされて、眉をひそめられています。 それらの人々は、彼らの物事のやり方を他人に追従させようと、飽くなき努力を続けているように見えます。 このウェブサイトは、PHP プログラミングに関する現実的な見解を示すために作られました。流行りのトレンド、理論、学問的な教示ではなく、経験と実践の帰着を書き記した視点です。 ウェブサイト PHP - The Wrong Way は生きたドキュメントですので、より多くの情報が明らかになるにしたがって更新され続けます。 お気軽にコントリビュートしてください。 翻訳 ドイツ語 英語 フランス語 日語 インドネシア語 トルコ語 ペルシャ語 ポルト

    kazutox
    kazutox 2021/01/13
    "Action or policy dictated by consideration of the immediate practical consequences rather than by theory or dogma." 末尾に文献いろいろ