自分を救うプログラミング｜naoya
子どものころは絵を描くのが好きだった。 学校の休み時間は、クラスメートはみな外にサッカーをしにいっていたが一人教室にのこってノートに漫画を描いている、そんな小学生だった。 自宅に戻っても、自室にこもってよく漫画を描いていた。 漫画と書くいっても、別に人を楽しませるために描いているわけではなかった。もちろん褒められると嬉しかったが、それが目的だったわけではなく、いま思えば、それは自分で自分を癒すかのような行為だった。自分を救うために絵を描いていた。 絵を描いているときは、それに夢中で没頭していて、ほかの何にも代えがたい時間を過ごすことが出来た。この時間が、どこか自分の救いになっていた。 中学二年生ぐらいになって思春期にさしかかった頃だろうか。教室で絵を描いていると浮いてしまうことに気づいて、恥ずかしくなって、描かなくなった。 それでもやっぱり絵を描いたりなにか作品を作ったりするのは好きだった
全ての開発者が知っておくべきUnicodeについての最低限の知識
2003年には「プレーンテキストなんてものは全く存在しない」と言われ、テキストの解読には文字コードの情報が必須となっていました。しかし、2023年になるまでの20年の間に絵文字などのおかげでUnicodeの利用率は98％へと到達し、再び文字コードを気にせずにすむ時代がやってきています。そんな時代において、正しくUnicodeを使うために必要な知識をエンジニアのニキータ・プロコポフさんが解説しています。 The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!) @ tonsky.me https://tonsky.me/blog/unicode/ Unicodeの歴史と利用率の推移をまとめたグラフは下図の通り。2000年代後半から急速に普及が進んでいったこ
Vacuous truth - Wikipedia
In mathematics and logic, a vacuous truth is a conditional or universal statement (a universal statement that can be converted to a conditional statement) that is true because the antecedent cannot be satisfied.[1] It is sometimes said that a statement is vacuously true because it does not really say anything.[2] For example, the statement "all cell phones in the room are turned off" will be true
毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記
開発しているアプリケーションのフロントエンドの様子を見る会（フロントエンド草むしり会）を毎週30分ずつ開催している。 式次第の雰囲気を紹介するとこういう形で、毎週見るメトリクスやエラーに加えて、月に1回くらい様子を見たい項目もある。 アップデート関連は、Pull Requestが出たら都度対処するのだけど、それに加えて最近の様子はどうだろう、と眺める時間を取りたい。そういうものは月に1回くらい見ることにしている。 毎週 この会の大義を確認しよう 終わってない宿題を眺めよう エラーのメトリクスを見よう パフォーマンスのメトリクスを見よう 月の初めの会のみ Dependency Dashboardのアップデート候補を見よう Dependabot alertsを見よう ここで「月の初めの会のみ」としているのがポイントで、今回が月の初めかどうかは誰が見ても明らかで、間違いが起きにくい。 これを仮に
Levenshtein Distance, Edit Distance
Algorithm (アルゴリズム) Dynamic Programming (動的計画法) Levenshtein distance (レーベンシュタイン距離) / Edit Distance (編集距離) [Up] 「ある文字列 s と別の文字列 t がどれだけ似ているか」 を判断したい場合があります。 それを表すのが編集距離 (Edit Distance) という概念です (レーベンシュタイン距離, Levenshtein distance とも言います)。 編集距離が小さいほど「近い」、すなわち「似ている」ということになります。 文字列 s に次の3種類の操作を加えて、文字列 t に変更するにかかる手間が編集距離です。 3種類の操作それぞれにコスト(cost, 手間)が設定されるのが普通です。 置き換え(substitute) ... sの中の1文字を別の1文字で置き換える。 例
プログラミングを勉強するために 30 代半ばの 2 年間を無職として過ごした話 - 30歳からのプログラミング
2019 年の夏に前職を辞め、そのまま無職として過ごし今年の 10 月にようやく再就職して働き始めた。 何か事情があって働けなかったわけではなく、プログラミングの能力を伸ばすために敢えて就職しなかった。 自分にとってそれなりに重要な期間だったと思うので、記録を残しておく。 予め断っておくが、何か「すごいこと」を成し遂げたわけではない。「すごくないプログラマ」が少しでもすごくなりたくて勉強していた話に過ぎない。 「すごいプログラマ」が「すごいこと」をした話を読みたければ、以下の記事などがよいと思う。 会社をやめて約1年プログラミングの勉強に費やしたことに対する満足と後悔 | blog.ojisan.io 2年間の独学をふりかえって – Happy Coder 予防線を張ったところで、本題に入る。 背景や動機 プログラミングの勉強をするために前職を辞めたわけではなく、退職の理由は別にある。 そ
できるだけ嘘を書かずに計算量やオーダーの説明をしようとした記事 - えびちゃんの日記
計算量についてのお話です。対象は、プログラミング経験はあるが計算量のことを知らない初心者から、計算量のことを知っているつもりになっている中級者くらいです。 数式を見たくない人にとっては読むのが大変かもですが、深呼吸しつつ落ちついて読んでくれるとうれしいです。 それから、この記事が自分には合わないな〜と思ったときは、（別の記事を Qiita とかで検索するよりも）この記事の一番下の 参考文献 にある本を読むことをおすすめします。Amazon の試し読みで無料で読めます*1。 TL; DR 関数の増加度合いのことをオーダーと呼ぶよ 計算量は、入力サイズ（など）を受け取ってアルゴリズムの計算回数（など）を返す関数だよ その関数のオーダーについての議論がよく行われるよ オーダーを上から抑えるときは \(O\)、下から抑えるときは \(\Omega\) を使うよ オーダーを上下両方から抑えたいときは
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
今さらProtocol Buffersと、手に馴染む道具の話 - Qiita
Protocol Buffersは別に新しい技術ではない。同時にそれは、未だ知られざる、未だに可能性を秘めた先端のソフトウェア技術基盤である。 新しくないのは事実で、GoogleがProtocol Buffersをオープンソース化したのは2008年のことだし、オープンソース化前に社内で使われ出したのは更に昔に遡るだろう。たぶん。 デザイン的にもJSON対応は後付けで、将来JSONが隆盛を極めることなんか全然想定していなかったのが透けて見えて古くさい。 しかし、同時にどうも情報に聡い人であってもなかなかその真価を実感し得ておらず、ある意味で未知の技術であるらしい。ならば、Protobuf (Protocol Buffersの略)を解説した文書は幾多あれども、それに1を加えるのもやぶさかではない。 Protocol Buffersとは Protobufはスキーマ言語だ! 一般的にはProtob
as a builder - Sexually Knowing
ソフトウェアエンジニアリングやると究極的には一行もコードを書かなければバグが混入することもないしなっていう気持ちになることがある。 それはテコを効かせるエンジニアリングの考え方として理に適っているので納得している。 早すぎた最適化とかは「やりすぎ」自体が問題なのではなく最適化という枝狩りの山はよく外れるからエビデンスを集めてからやれということだと思うし、最初から将来に渡ったユースケースもカバーしてめちゃくちゃ速いものを作れるならそれに越したことはないはず。 一方でソフトウェアコンストラクションという手段にこだわりたい自分もいて、この時折顔を見せる自分はなんだろう、とずっとモヤモヤしていた。 ふとこれはビルダーとしての自分だなと気がついた。作ることが手段であり目的でもある存在としてビルダーというラベルはしっくりくる。 常に便利なソフトウェアを作ってものごとを良くしていくというやりかたにこだわ
ARCHITECTURE.mdというものを書いてみた - maru source
こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru
独学でプログラミングを勉強した自分がこれは役に立ったなと思っている本 - golden-luckyの日記
今ではプログラミングできないわけではないけど、そういえばプログラミングは完全に独学と言っていい。 いや、大学では数学をやっていたので、FortranとかLispはちょっとやった。 なので「完全に独学」といったら嘘になる。 それでも、いま仕事で使っているコンピューターの知識は、基本的にすべて書籍を通して独学したものだ。 そこで、自分が何の本を読んでプログラミングを実務で使えるくらいにはなれたのか、アフィリエイトと宣伝を込めつつちょっと振り返ってみてもいいかなと思って走り書きしてみる。 テキストフィルターを書きまくるとこから始めるといいと思う プログラミングぜんぜんやったことない人が「プログラミング完全に理解した（ダニング・クルーガー的な意味で）」という実感の端緒を得るまでには、まず「テキストフィルタを書きまくる」のがわりと近道だと信じている。 コンピューターを使うことがインターネットを使うこ
Iterator パターンの本質 · eed3si9n
2011-12-17 これは Scala Advent Calendar 2011 の 17日目の記事です。 specs2 の作者であり、@etorreborre としても活発に発言を続けるシドニーの強豪 Eric Torreborre さんが書いた “The Essence of the Iterator Pattern” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。 2011年6月24日 Eric Torreborre 著 2011年12月17日 e.e d3si9n 訳 去年読んだ論文で一番気に入ったのは “The Essence of the Iterator Pattern”（以下、EIP）だ。これを読んだ後で、今まで何年も使い続けてきたあるものに対する考えがガラリと変わった。それは、for ループだ。 この論文の中からいくつか
Early Work
初期の作品 --- Early Work Paul Graham, October 2020 これは、Paul Graham： Early Work を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2020 by Paul Graham 原文: http://www.paulgraham.com/early.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。 出版社の案内ページ Amazon.co.jp サポートページ 2020/10/20 翻訳公開
Functor / Applicative / Monad が表すもの
https://kazu-yamamoto.hatenablog.jp/entry/2019/04/11/111238 の記事に触発されて，ちょっと書く気になった．こちらも面白い記事なので，ぜひ参照してほしい． Haskell 2020 で Applicative が追加される見込みだ (そもそもちゃんと 2020 年に出るのか怪しそうだが)．それを踏まえて，標準ライブラリに入る Haskell の特徴的な一連の型クラス Functor / Applicative / Monad の個人的な捉え方を書いておこうと思う．なお，あくまで個人的な捉え方なので，形式的でないし，広く受け入れられている考え方とは乖離している可能性があるので，そこは注意してほしい． 概要 それぞれの型クラスが表すものは端的に言えば， Functor 変換の一般化 Applicative 関数適用の一般化 Monad 手
マルチスレッド・プログラミングの道具箱
まえがき クラウド上の仮想サーバから手元のスマートフォンまで、いまや複数のCPUコアを搭載するマルチコアはどこにでもある環境になりました。ハードウェア側が並列(Parallel)・並行(Concurrent)処理に向けて急速に進化する一方で、ソフトウェア側つまりプログラミング言語の進化はさほど追い付いていません。並行処理記述の手軽さを求めた Go言語 や、マルチスレッド処理の安全性を重視する Rust言語 などが登場してはいるものの、「普通にプログラムを記述するだけで複数CPUコア環境で高速に走るプログラミング言語」は遠い夢物語のままです。 モダンなプログラミング言語や並列・並行処理ライブラリは、複雑で難解なマルチスレッド処理を直接記述しなくてすむよう、安全性・利便性の高い抽象化レイヤを提供します（例：Go言語のgoroutineとchannel、Rust言語の Rayonライブラリ）。し
条件変数の利用方法 - cpprefjp C++日本語リファレンス
標準ヘッダ<condition_variable>で提供される、条件変数(condition variable)の利用方法について説明する。 簡単のため、条件変数condition_variableとロックunique_lock<mutex>の組に対してのみ説明を行う。 condition_variable_anyクラスは、任意のロック型と組み合わせ可能なことを除き、その利用方法はcondition_variableと同じである。 利用の目的 条件変数オブジェクトのみを単体で利用するのではなく、必ずミューテックス（排他制御）オブジェクトと、同ミューテックスで保護されるデータ状態を表す変数群（以下、"ステート"と呼ぶ）という3つの組で利用すること。 条件変数オブジェクトとは、複数スレッドがこの共有"ステート"を更新／参照する場合に、"ステート"の更新を他スレッドに通知／"ステート"が指定条件
Should I Test Private Methods?
should i test private methods?
契約による設計とテスト駆動開発で大きいタスクを楽にする - shallowな暮らし
こんにちは。id:shallow1729です。先日一ヶ月ぐらいの工数のかかる大きめのタスクを担当しました。そのタスクは機能に関連するテーブルやエラーになる条件が多く、初めはどこから手をつけたらいいか分からない状態でした。今回紹介する契約による設計とテスト駆動開発は自分がうまくとっかかりを見つけて手を進める上ですごく役に立った開発手法です。うまく実装を進められない時とかに思い出してもらえたらと思います。 大きいタスクの難しさ これはエンジニアとしての経験則ですが、規模の大きい機能の開発はたとえそこにアルゴリズム的な困難さを伴わなくても難しいものになるように思います。 もちろん全体のアーキテクチャを考えるには設計手法の理解が必要ですし、関連するツールが増えるとそれらの理解が必要だったりするので技術的な課題に直面しやすいというのも事実だと思いますが、実際に開発をしている中でそういう技術的な課題感
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
