Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どういうわけか日本では一切話題に上がっていないのですが、Pythonの開発者コミュニティでなんか問題が起きているようです。 どうも話が様々なスレッドにとっ散らかっているうえに半分はDiscordや非公開のところで動いているみたいなので、読み取れていないところが色々あるかもしれません。 誰かが補足してくれるはず。 Proposed bylaws changes to improve our membership experience 最初のきっかけはこのスレッドです。 これは規約の一部を変更する提案であり、その中でも3番目の提案であるAd
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※ 本記事は WESEEK Tips wiki の記事 "/Tips/BuildKitによりDockerとDocker Composeで外部キャッシュを使った効率的なビルドをする方法" の転載です。 本記事を執筆したモチベーション Docker Hub の Automated Build 機能を GitHub Actions へ移行する機会がありました。 移行をするだけであれば GitHub Actions で docker コンテナをビルドすればよいのですが、せっかくなので BuildKit を調べて使ってみることにしました。 本記事
こんにちは。最近、Reactでのステート管理において「useStateの中にステートを置くのではなく、useRefで得たrefオブジェクトの中にステートを置いてuseState(またはuseReducer)をコンポーネントの再レンダリングを発生させるためだけに使う」というやり方を複数の記事で見かけました。このパターンは、今(React 17以前)は動くけどReact 18でアンチパターンに変貌するやり方なので、啓蒙するためにこの記事を用意しました。 ステート(コンポーネントのレンダリングに使用される値)は、useRefではなくuseState(またはuseReducer)をちゃんと使って管理するようにすれば、React 18以降も安泰です。 useRefをステート管理に使うパターンとは こういうやつです。 // 普通のやり方 const Counter1: React.VFC = () =
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
動機 最近、chatGPTにいろいろ尋ねるのが流行っているらしい。Haskellで有名なモナドの概念がなぜ導入されたか尋ねている人を見かけて、そういやそういう記事見たことないなと思ったので適当に調べた。 一次ソース 元ネタは以下のマイナーだと思われる文献 An abstract view of programming languages Eugenio Moggi教授のあんま読まれてない方の論文 Denotational Semantics Peter D. Mosses教授のこの論文(2部あって後半の方) 邦訳があり邦訳で読んだ。 プログラミングのモナド発見の経緯 プログラミングのモナドはなんか包んだり抜き出したり見たいな感じの概念で知られてますが、プログラミングの概念をモジュール化する機構云々の開発の前段階がある。そもそもリストだかIOだか例外処理だかの概念をそれぞれ一つのモジュールに
はじめに JavaScriptにて文字数をカウントする方法に関する記事をいくつか目にする機会があり、今回実際に記事を参考に調べてみました。 簡単そうに見えて意外と難しいです。 String.length Googleなどで「JavaScript 文字数 カウント」とかで検索すると真っ先に出る方法です。 MDN公式ではString.lengthに関して以下のように説明されています。 length プロパティは String オブジェクトの文字列長を UTF-16 コードユニットの数で表します。 length は、 string インスタンスの読み取り専用データプロパティです。 UTF-16 コードユニット ざっくりと説明するならUnicodeで割り当てられた番号をUTF-16 という文字コード方式で割り当てられた各文字に対応するIDを指します。 難しい単語がいくつか出てきているので1つずつか
その名はBun デデン BunはNode.jsやDenoのようなJavascriptランタイムです。(2022/7/8現在ベータ版) ちなみにロゴが本当に肉まんなのかはわかりません。(赤ちゃんの頭にも見えるけど名前がBun/パンだしなぁ...) この記事ではNode.jsやDenoと比較をしつつ、bunの解説させていただきます。 割となんでもできる Bunはただのランタイムではありません。下のように、開発に必須の多くな機能を最初から有しています。 TypescriptからJavascriptへのトランスパイル jsxからJavascriptへのトランスパイル npmのようなパッケージのインストール&管理 webpackのようなプロジェクトのバンドル化 もちろんランタイムなのでNode.jsのようにサーバーでJavascriptを実行することも可能です。 これらに加えてBunには様々な機
JavaScriptの文字列や配列は最長でどこまで格納できるか、気にしたことはありますか?関数は何個まで引数を取れるのでしょうか?ブロックのネストは何段まで? この記事では、そんな素朴な疑問に答えてみます。 テストに使った環境は、 macOS 12.3.1 (Arm64) Node.js v17.7.2 Firefox Nightly 102.0a1 (2022-05-29) です。当たり前ですが、この記事に載せる数値は環境によって変わる可能性があります。 テストに使ったスクリプト類は https://github.com/minoki/javascript-limits に置いてあります。 文字列の長さ まずは文字列の長さです。 規格には The String type is the set of all ordered sequences of zero or more 16-bit
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 現代のC++で例外安全問題を抜きにして、障害に強い強固なコードを書くことはほとんど不可能に近い。以上。 Hurb Sutter [1] 例外処理における目的は、例外の回復と例外の通知の大きく2つあります。残念ながら例外の回復はとても難しく、場合によってはそもそも不可能だったりします。その場合、例外が発生したことをより上位のレイヤーに通知する事で例外処理を託します。この時、例外の通知を受け取った側は何を前提に例外の回復を行えばよいでしょうか。例外の発生によってデータ整合性は崩れてしまっているかもしれません。通知を受け取った上位レイヤーはあ
ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです(記事執筆時点1)。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのはPromiseをthrowするというAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした(Promiseが解決されるまでレンダリングできない)ことを表します。 Concurrent Modeに関しては筆者の既存記事Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点
2024年3月末にライセンスが全面的に改訂されました。 以前とは異なり、教育機関はカリキュラムベースのコースの使用のみに限定される場合には免除されるという条件が明記されました(Educational Entities will be exempt from the paid license requirement, provided that the use of the Anaconda Offering(s) is solely limited to being used for a curriculum-based course.)。 つまり、教育機関で研究目的の利用時は200人以上の組織であれば有償ということがはっきりしたことになります。 以前も「教育活動に関連して使用する場合(use by a student or employee of an educational insti
既に Stage 4 になっているので諦めていたんですが、流石に見逃せないかなと思ったので TC39 の Discourse にトピックをたててみました。意見がある方はこちらにお願いします。 https://es.discourse.group/t/fix-at/983 議論に伴って私が実際に欲しかったものをモジュールにして公開してみました。 https://github.com/petamoriken/safe-at それといまいちユーザーからの声が伝わっていない感じがしたのでハッシュタグ #fix_ecmascript_at を用意してみました。協力をよろしくおねがいします。 String#char{At, CodeAt} という存在を忘れてたんですが、この似た名前のメソッドたちが引数を整数に丸めるのに String#at が丸めないのはたしかに変だということに気づいてしまったので、自
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
不思議の国 SEが住んでいるところ、そこは不思議な不思議なお国柄です。 新たな国民として移住してきた人、特産物のシステムを買いに来た人など色々な人がこの国には存在します。 しかしこの国で話される言葉は 独特 です。 ぱっと聞いただけでは意味がわからなかったり、よく似た表現であっても微妙にニュアンスが違っていたり。 似たような表現を使い分けるその裏に、その人の意図や省略された文脈が隠されていたりもします。 どこの国でもコミュニケーションを間違うと非常に厄介ですが、そんなことにならぬよう、 お国言葉らしきもの をまとめてみました。 SEを代表例として、このお国言葉を話す人も、話される人も、改めて言葉の意味合いを見つめなおしてみると新たな気付きが得られるかもしれません。 なお、そんなことから 「絶対にSEしか使わない用語」を集めたわけではない のでその点ご了承くださいませ。 他言語版 @micr
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Java 16が2021/3/16にリリースされました。 多くのプログラマに関係ありそうな変更は、record、instanceofパターンマッチの正式化、Stream.toListです。またTLS1.0と1.1が無効になっているので古いMySQLなどへの接続でハマることがあるかもしれません。 詳細はこちら Java SE 16 Platform JSR 391 JDK 16 GA Release APIドキュメントはこちら Overview (Java SE 16) MacやLinuxでのインストールにはSDKMAN!をお勧めします
この記事は NIJIBOX Advent Calendar2019の13日目の投稿です。 #背景 何かしらのロジックを作る際に、仕様変更に強いコードを書きたいぞい!ってエンジニアだったら思いませんか。今の仕様なら動くけど、もし仕様が変わり、そのために関数全書き直しとかしんどみが深すぎます。今回はこのしんどみを少しでも回避できるように柔軟なコードを書くぞい!って記事です。 ページネーションコンポーネントを例にしますが、なぜページネーションなのかというと僕が最近業務でページネーションを作り、かつ仕様の変更に強いコードの大切さを実感したからです。 #そもそもページネーションとは ページネーション(pagination)とは、日本語で丁付け、ページ割りという意味で、Web制作においては、検索結果一覧など、内容の多いページを複数のWebページに分割し、各ページへのリンクを並べてアクセスしやすくするた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く