SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか?をまとめました。
哲学者の東浩紀さんと思想史と近代科学史(特にコンピュータ史)の本を一緒に書いてみようという企画が今年から立ち上がった。 すると東さんがある日の生放送で、「しかし俺も最低限プログラムくらいかける必要があるんじゃないか。しかし最低限のプログラムとは何か」と言っていたところ、シラスの桂さんが「エラトステネスの篩ふるいとかですかねえ」と言っていて、もうエラトステネスと聞いたら黙ってはいられない吾輩が怒涛の勢いで生放送したところ、東さんが一番乗りで入ってきてくれたのでその場でライブコーディングしながらプログラムの書き方を簡単に教えることにした。 https://shirasu.io/t/zelpm/c/shi3zlab/p/20240105163405 プログラミング言語習得のコツプログラミング言語は、言語であるため、マニュアルを頭からお尻まで読んで内容を暗記するよりも、「これってどうやんの?」「こ
いわゆるトンデモに関して私が思うことを何点か書いておく。 何を問題にしているか ここで問題にするのは、例えば以下のような表現物である: 初心者にとって有害である。つまり、間違った理解を植え付ける。 誤りを修正したら何も残らない。 すべきではない対処 まず、作者に突撃して撤回させるのはあまり現実的ではない。指摘を受け入れて撤回するなら良いが、「自分の表現物が無意味あるいは有害だった」ことを受け入れられる表現者がどのくらいいるだろうか?あるいは、SNS上でバトルに発展した場合不毛な時間を費やすことになる。 第二に、作者に対する人格攻撃や侮辱的な表現は行うべきではない。具体的に言うと、2021年にプログラミング界隈を騒がせた件(「関数型プログラミングが『銀の弾丸』であるという非常識な常識2022」の感想の言及先)の作者を「漢字1文字+ひらがな1文字+漢字1文字」で呼んだはてなブックマークユーザー
0. はじめに 基本的なデータ構造として大学の授業や情報系の各種試験などによく登場するものの一つに、スタックとキューがあります。 スタックとキューについて学ぶ場面の多くでは、「スタックは LIFO (Last-In-First-Out)、キューは FIFO (First-In-First-Out)」と呪文のように覚えたり、 スタックは、例えば超忙しいときに新しい課題がぶっこまれたときとかにとりあえずそれを先に片付けるような感じ キューは、人気ラーメン屋に並ぶ人々の待ち行列のように先に並んだ人が先にお店に入る感じ という風に、日常の事物に対応づけて説明したりする文化が多く見受けられます。「タスクが次々と降ってくる状況をどう扱っていくか」というのは、日常生活を生きる人間にとっても、コンピュータ上の処理であっても自然に登場する普遍的な問題意識ですので、その最も基本的な思想であるところのスタックや
はじめに gcc v12.1において、C++の正規表現ライブラリstd::regexに、正規表現のバリデーションを改善するパッチ(以下"改善パッチ"と表記)が取り込まれました。改善パッチによって、これまではバリデーションにひっかからなかった不正な正規表現文字列が"正しく"不正なものと認識されて例外が発生するようになりました。 これだけ聞けばいいことだけのように思えるかもしれませんが、実はそうでもなかったりします。経験豊富なかたであれば見た瞬間ゾッとしたかもしれません。本記事では、この一見問題なさそうな改善パッチによって発生しうる問題、および、その具体的例について紹介するとともに、この手のパッチを当てるかどうかは難しい判断になるという知見を共有します。 結論 改善パッチによって発生する問題 発生条件 gcc v12.1以降、あるいは改善パッチをバックポートされた任意のバージョンを使ってC++
プログラミングに興味がある人たち、どうか「自分はプログラミングに向いてない」と思わないでほしいです。 プログラミングスクール通ってるかどうかとかどうでもよくて、この年末年始にコード全く書いてない人はエンジニア向いてないんじゃないですかね、それぐらい好奇心が必要な職業だとおもうけど— キュン / 今村雅幸 / ZOZO CTO (@kyuns) 2021年1月3日 たしかに「プログラミングスクールに通ってるから」良いスキルがあるわけではないし、スクールよりも好奇心のほうが重要なのは僕も同意です。 というか基本的な考え方はたぶんこのツイートをしてる方と、僕は同じだと思います。僕もうっかりこういうことを言うこともあります。 実際、本当に大好きで休日もプログラミングしてしまう人のほうが、スキル面で伸びが早いのも当然でしょう。 でも「休日にもプログラミングしてしまう」ほど好奇心を持って好きになるにも
1.具体的な事が分からないプログラミングで主にやる事は下記の2つ。 ①IFでAかBを選択させてどっちかの設定を実行 ②Whileで決められた回数分繰り返す これでやりたいことは分かる。分かるけれどこれでどうやって動画や音楽のエンコードをしたり 画像処理をしたりするソフトウェアになるのかというのがよく分からない。 あるいはWordとかExcelとかがどうやってこんなので作られているのかが分からない。 プログラミング入門書を読んでも、一般的に知られているソフトウェアの作り方みたいな事が 書いてないので、ゴールが見えてこない。だからうんざりしてくる。 入門書を読むと、判定と繰り返しとあとどこかからかそういうプログラムが既に作られている フレームワークだとかよく分からないものを持ってきて使ってくださいってなっている。 だからそのフレームワークがどういう風になっているのかって説明からして欲しいって思
anond:20201130214610 いろいろ面白かったので、適当に回答する。 > 1.具体的な事が分からないプログラミングで主にやる事は下記の2つ。 ①IFでAかBを選択させてどっちかの設定を実行 ②Whileで決められた回数分繰り返す これでやりたいことは分かる。分かるけれどこれでどうやって動画や音楽のエンコードをしたり 画像処理をしたりするソフトウェアになるのかというのがよく分からない。 とてつもなく複雑で冗長な処理によって実行されている。 複雑すぎて人間の直感で理解することは不可能だ。 わかりやすいので画像処理でいうと、数十万から数百万の画素(RGBAの24bitで表される数値)を小さなブロックに分解し、数学的に周波数の重なりとして計算して変換、含まれる頻出パターンをテーブルにして圧縮伸張を行なう。みたいなことが瞬間的に行われている。 「まさかそんな事できるわけないだろ」という
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高(大きな損失を生む問題・後からの修正が困難な問題) 優先度中 優先度低(システムに大きな影響を与えない問題・後からの修正が容易な問題) レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
なかめのくまちゃん@質問アプリQuerie.me開発者 @wgextra 「ディスプレイの脇に置いたアヒルちゃんに実装した処理を一行ずつ説明する中で実装者自らがバグに気づき、デバグして品質を高める」ラバーダックデバッグっていう手法があるんだけど、絵面だけでも草なのにどうやらマジで効果絶大らしく、もうこんなん大草原不可避だわ。アヒルちゃん買ってこよ。 pic.twitter.com/80zqajvdPV 2020-07-05 10:24:15
はじめに コードを綺麗に描く方法やプログラミングの勉強方法や考え方など、 個人的にとても為になって感謝している記事をまとめてみました。 コード関連 良いコードを書く技術(まとめ) Naming -名前付け- ソースコードを汚くするには? ダメエンジニアの8つの特徴 勉強方法関連 新しく言語を学ぶときに心がけていること 深夜だから個人的なプログラミング学習方法を書くよ! 【まつもとゆきひろ氏 特別講演】20代エンジニアのためのプログラマー勉強法のまとめ 2019/3/30 知識が無いからこそコードレビューで指摘をしよう 考え方関連 レガシープロジェクトを引き継いだ時、最初にするべき7つのこと ハッピーな開発🎉をするための、プロジェクトにおける要件定義の役割 [初心者]オブジェクト指向でなぜつくるのか ビルドとデプロイとリリースの違いについて AWS (下準備編)世界一丁寧なAWS解説。EC
どうしてプログラマに・・・プログラムが書けないのか?を読んでいて出てきたので出展の一つを訳してみた。Separating Programming Sheep from Non-Programming Goatsの和訳。 プログラミングというものには向き不向きが強く出るということはわりと知られていると思うが、このエントリではプログラミングができるかできないかは比較的簡単なテストによって、プログラミングの訓練を始める前の段階で分かると主張している。どうしてプログラマに・・・プログラムが書けないのか?では、そもそもこの事前テストをパスしていないような人達までプログラマとして応募してくると言っており、その判定法として有名なFizzBuzz問題を挙げている。 追記(2019/2/28) 注意: なおこの論文はしばらく前に著者の一人によって撤回されたようです Camels and humps: a r
オリジナルはココです。フェイスブックのエンジニアで史上ベスト3に入るといわれるEvan Priestley氏への質問「どうやってプログラミングを覚えましたか」に対する本人からの答えです。 手短かに言えば 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、(フェイスブックで働いていた)過去4年間、ほとんど他のことをしていない。その前も2.5年ほどプログラマーとして働いていたし、そのさらに前も6年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで(最初はMac Plusで途中からIIsiになった)で散々遊んだ。8歳か9歳の
もしかしたら私だけかもしれないです。ずれているかもしれません。 一般論ではないかもしれません。 でも、同じような気持ちになっているエンジニアがいるかもしれないので、 代表して言わせてください。 エンジニアに、気軽に「バグ」と言うのをやめませんか? 最近立て続けに以下のようなことが起こっており、私と同僚が消耗しています。心がすり減ってます。ワーカーエクスペリエンスが低下しています。。。 ~~~~~~~~~~~~~~~~~~~ 「○○さん、この数値がバグなんだけど直してもらえる?」 →調べたらその週は祝日影響で、営業日が少ないだけだった。 「あのデータのバグはいつ直りますか?」 →データの集計定義の変更の依頼があり、変更前の状態をバグと呼ぶ 「この前入ってなかったバグなんだけど、次の開発に入れてもらっていい?」 →スコープ外のこと(担当がそれを忘れていた)をバグと呼ぶ ~~~~~~~~~~~~
質問箱というサービスを使っているのですが、多くの質問をいただいております。未返信が1000件を超えちゃいましたが、気が向いた時に返信しています。 で、どんな質問が多く来るかというと、たとえば「プログラミングを学びたいけどどうすればいいのか」「やりたいことが見つからないけどどうしたらいいか」とかです。 これ、毎回答えてたんですが、あまりに同じのが来るので放置するようにしちゃいました、、すいません。 で、多い質問の中に「フリーターだ / 受験失敗した / ニートだ」という前提の元、「人生詰んだけどどうしたらいいか」「一発逆転をするにはどうしたらいいのか」というやつです。 これは結構答えに困っちゃうんですよね。というのも、一発逆転って、要はミラクルみたいなもんなので、あまりにハイリスク的すぎてすすめられません。一発逆転をしようとすると「消費者金融で金を借りまくって全額、暗号通貨にぶち込む。利益が
前置き 正直に答えてください。 あなたが1日に集中してプログラムを書ける時間の長さは? 12時間?11時間?9時間? はい。 あなたはスーパープログラマーです。人間を超越していると言ってもいい。このポエムはなんの役にも立たないのでさっさとエディタに戻って人類の未来に貢献してください。 8時間?7時間?6時間? 本当? すごい。ほんとうにすごい。引き続き頑張ってください。きっとあなたはコードに選ばれた人です。 しかしあなたにもこのポエムは役に立ちません。 そっとブラウザのタブを閉じて頂ければと思います。 4時間?3時間? はい。ようやくめぐりあえましたね。あなたのような方をお待ちしておりました。 こんなに集中していられる時間が短いなんて、問題があるのでは、、とお考えかもしれません。 後ろめたい気持ちにとらわれることがあるかもしれません。 その気持ちを埋め合わせるために、終電間際まで仕事し 「
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 コンピュータサイエンスの専門教育を受けず、20代半ばで本格的なプログラミングを始めた文系エンジニアが、いかに学び、考え、生き延びてきたのかを伝えます。 こんにちは。白山(@fushiroyama)と申します。現在は新聞社のデジタル事業部署で、モバイルアプリ開発のテックリードをしています。 自分のエンジニア人生を振り返ると、これまでの道のりは決して平坦ではありませんでした。コンピュータサイエンスの専門教育を受けず、本格的にプログラミングを始めた年齢も23、4歳と決して早くありません。 そんな自分が、いかにして開発チームのリーダーを任せてもらえるまでになったか? 考えてみると、次の4つの戦略で生き延びてきたようです。 自分だけの居場所を見つける 必要な知識を効率的に取捨選択する 他のエンジニアに差を
4月からプログラミングを教える仕事を定期的に行っていて、集合研修という形が1つ、実験台としてプログラミングに興味がある学生の甥っ子に対してマンツーで教えています。自分の教えている内容がどう伝わるか、どんなイメージ絵を描けばいいのか、どの順番で説明すればよいのか。それらを検証するためです。 で、そんな中、甥っ子がポロッと漏らしました。 「おれ、やっぱりプログラミングのセンスが無いんだと思う。教えてもらっても全くわからないことが多いし...」 「ちげーだろ。お前は単なる練習不足にすぎない。2〜3回しか練習していないのに、どうやってオレと同じレベルで物事が判断できるんだって話。ちょっとしか練習してないのにセンスもクソもない。漢字の書き取りにセンスが必要か? 100回while文書いてみたか? 書いてないだろ? 」 「あ・・・(察し」 センスは練習不足の免罪符じゃない 彼が言っていたセンスがあると
新人プログラマのうちに身に付けたい習慣(この半年で学んだことと反省) はじめに 半年よりちょっと前に未経験からプログラマになりました。 プログラマと言っても、この約半年間はほとんど研修を受けさせていただいていた感じなので、偉そうなことは言えません。 しかし、この約半年で反省したことや学んだことを自戒の念も込めて、まとめました。 主体的に学ぼう 能動的に自ら学び、自走しましょう。 新しい技術を学ぶということは非常に楽しいことです。 すごい先輩方は大抵、新しい技術を身につけるためにその技術を学ぶことを「その技術を勉強した」というよりも、「その技術を使って遊んでみた」と表現している気がします。つまり、必要だからしょうがなく学ぶのではなく、半ば趣味として新しい技術で遊んでいたら、身についたーという感じでしょう。 教えてもらって学ぶという姿勢ではなく、自ら楽しいから学ぶ(=その技術で遊んでたら身につ
レールに乗らないで起業するのがブームみたいなので、レールに乗ったまま話もしようかなぁ、と思ったので、書いてみます。 参考: (2021/04/01追記 リンク先が危険なページになってたので、リンクを削除しました。) 過去を語りながら起業に至った経緯を語るのが流行ってるみたいなので、便乗しようかなあ、と思います。もう5年目だけどねw 中学・高校時代 小学校時代は、算数が得意で、筑駒って言う凄い中学に入りました。 でも中学だと、それが全然通用しませんでした。得意分野ならついていけるものの、苦手科目はお話にならず、下1割から2割の成績でした。このあたりで僕は悟ります。僕はそれなりに頭がいいけれども、トップクラスと戦えるほど、平均的に頭が良い人間ではない、ということを。 高2で肘を壊し野球部をやめ、パソコン研究会に頻繁に顔を出すようになります。といっても、そこではボードゲームや麻雀やパソコンのフリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く