PDF形式のファイルを御覧いただく場合には、Adobe Acrobat Readerが必要な場合があります。 Adobe Acrobat Readerは開発元のWebページにて、無償でダウンロード可能です。
高等学校情報科「情報Ⅱ」教員研修用教材(本編)：文部科学省
PDF形式のファイルを御覧いただく場合には、Adobe Acrobat Readerが必要な場合があります。 Adobe Acrobat Readerは開発元のWebページにて、無償でダウンロード可能です。
プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話 - 覚書
家にパソコンがはじめて来てから30年くらい、プログラミングを始めてから20年以上が経ちました。その間、IT技術に対する愛は変わらずに、ずっと走り続けてきました。では当時の自分と今の自分で何が違うのだろうと考えてみたところ、めちゃくちゃ変わっていたのでびっくりました。本記事では何がどう変わったのか、それを見てなにを思ったかなどを書きます。 昔は次のようなこだわりがありました。 大きなものは一つの仕事をする単純で小さなツールを組み合わせて作るべし ソフトウェアは可能な限り設定可能になっていてほしいし、それを自分の好みになるまでカリカリチューニングしたい 可能な限りすべてキーボードだけで操作できるようになっていてほしい いわゆるUNIX哲学をはじめとして、いろんな本やWebサイトなどに強い影響を受けていることがよくわかります。 ところが今は次のように全然違うことを考えています。 トラブルハマった
書き手の意図やコードの背景を残す方法のあれこれ −きれいなコードの次に意識すべきこと− - give IT a try
はじめに 先日、こんなエントリを書きました。 blog.jnito.com 上の記事の中で、僕は「きれいなコードだけではすんなりコードが理解できないこともある」というような話を書きました。 もちろん、ある程度の規模になってくるといくらがんばっても「すんなり」では済まない場合も増えてくるけど、それでも最初に挙げた特徴を兼ね備えたコードとそうでないコードでは、開発効率に雲泥の差が出てくる。 僕が考える「良いコード」 - give IT a try きれいなコードを書くことはいつでも大事ですが、きれいなコード「だけ」では大きなコードを理解するのは難しいです。 そこできれいなコードを書くことに加えて、僕が意識しているコードを理解しやすくする工夫について書いてみようと思います。 ただし、ここで書く内容はあくまで僕が普段心がけていることです。 現場の文化やコードの規模や歴史、開発チームのスキルや人数、
Pull Request のコメント数を減らすアホみたいなコツ｜牛尾 剛
私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは２時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう？すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー
『プログラミング文体練習』を読んだ
プログラミング文体練習 ―Pythonで学ぶ40のプログラミングスタイル という本を読みました。本書はある文章の中に含まれる単語の頻度を集計するという処理を題材にして、それを40種類の手法で実装していくという少し変わった本です。目次は以下になります。 見ての通り、低レベルなところでいうとアセンブリやスタックヒープ縛りのようなスタイルから関数型やOOPを用いた実装など現代的なスタイル、果てはニューラルネットワークまで多岐にわたります。実装言語としてはPythonが採用されているため低レベルなプログラミング(主にメモリへの直接アクセス)や末尾再帰の実装では無理がある部分もありますが内容を理解するという点では問題はないでしょう。この本で重要なのは具体的な実装コードというよりもそのプログラミングスタイルが生まれた背景は何だったのか？ということであり、それらがコンパクトに各章まとめられている点が見ど
プログラミング文体練習
レーモン・クノーの『文体練習』から着想を得て執筆された本書は、1つの課題を異なるプログラミングスタイルで実装し、さまざまなスタイルの特性やスタイルが生まれた歴史的経緯などを解説します。本家の『文体練習』は、「バスの中で起きた諍いと、その張本人を後で目撃した」という内容を、公的文書風、宣伝風、業界用語風など、99の異なる文体で表現したものですが、本書は、「単語の出現頻度をカウントして多いものから出力する」という課題を、40のスタイルで実装しています。リソース制約が大きかった時代の方法から、オブジェクト指向、純粋関数型、リフレクション、並行処理、ニューラルネットワークまで幅広いスタイルを扱い、マルチパラダイム言語Pythonの威力と魅力を感じられる構成となっています。 訳者まえがき 第2版 まえがき 第1版 まえがき 序章 第Ⅰ部 歴史的スタイル 1章 古き良き時代：アセンブリ言語 2章 Fo
私たちが知っているプログラミングはいよいよ消滅する
この数十年の間に、さまざまなムーブメントや、パラダイム、テクノロジーの波がソフトウェアの世界を席巻した。その中には、プログラミングの煩雑な作業の多くをエンドユーザーに委ねるものもあれば、あるいはそのプロセスを自動化すると約束するものもあった。CASEツールや4GL、オブジェクト指向プログラミング、サービス指向アーキテクチャ、マイクロサービス、クラウドサービス、Platform as a Service（PaaS）、サーバーレスコンピューティング、ローコード開発／ノーコード開発などは、理論上、どれもソフトウェア開発の煩わしい作業を減らすことになっていた。つまりこれらは、潜在的には開発者の雇用の安定を脅かす存在でもあったわけだ。 しかし今も開発者の仕事はなくなっていない。それどころかソフトウェア開発者はますます忙しくなっており、スキルを持つ人材の需要は高まる一方だ。 人材開発支援会社であるPl
好きなの使って他のをけなさない - 覚書
私が生業とするソフトウェア開発において、OSやコードエディタやプログラミング言語など、様々なソフトウェアを使います*1。これらについて私が使っているものを理由付きで書くと次のようになります。 OS: Ubuntu 22.04 細かい設定をしなくてもそれなりに使える。よく普及しているから色々な情報を得やすい コードエディタ: VSCode 細かい設定をしなくてもそれなりに使える。Remote SSH extensionを使ったリモートマシン上での開発が楽 プログラミング言語: 主にGo 使い慣れているから。システムプログラムをするから。覚えやすいから これらにそれなりの愛着はあるものの、今後置かれる状況によって、どんどん変わってくるでしょう。じっさい10年くらい前はGoはほとんど使っていなくて、Cプログラマでした。 私はこんな感じですが、中には特定のソフトウェアに愛情を注ぐ人もいます。それ自
プログラミング言語の入門が終わったら何の勉強をすればいいの？ - きしだのHatena
JJUG CCC 2022 Fallで「Javaの入門が終わったら何の勉強をすればいいの？」という内容で発表を行いました。 基本的なものが作れるようになったけども、イマイチプログラムが組めないというときに、何を勉強すればいいかをまとめました。 入門が終わって作りたいものがあれば作っていきましょう、業務で言われたものが作って行こう、でもなんだかちゃんとしたものが作れないな、もっとちゃんとしたものを作りたい、次のステップに進みたいというときに勉強していく感じです。 資料はこちらです とりあげた本についてまとめておきます。 開発作業について 概要 プログラミング言語 アーキテクチャ ミドルウェア ネットワーク デプロイ 理論 開発手法 開発プロセス まとめ フレームワークは入門でやってる前提です。Java入門書「プロになるJava」ではJavaの基本から簡単なDB操作、Spring Bootまで
LintオタクによるLint解説 / Introduction to Lints
https://lintnight.connpass.com/event/263931/
ファミコンで動くソフトを自作しよう、カギはグラフィックスの理解
ファミリーコンピュータ（ファミコン）をはじめとして、昭和＆平成の時代には多くの家庭用ゲーム機が生まれた。そうしたゲーム機で動くプログラムの開発には独自のノウハウが必要だ。「ファミコン」「ゲームボーイ」「PCエンジン」「メガドライブ」の4つのゲーム機で動くプログラム開発の基礎を解説する。 個々の部品は複数の信号線でつながっています。信号線の束は「バス」と呼ばれます。バスは「アドレスバス」と「データバス」の2種類ありますが、図1ではわかりやすくするために1本の線で表現しています。 ファミコンの頭脳であるCPUはリコー製の「2A03」です。これは、当時人気のあった米モステクノロジーのCPU「6502」と互換性のある8ビットCPUです。ただし、6502の一部の機能が省かれていて、代わりにサウンドの出力機能である「APU」（Audio Processing Unit）を搭載しています。 図1にあるP
コードレビューのときに見ているところ - 詩と創作・思索のひろば
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
先輩エンジニアから「メモリを意識してプログラムを書かないやつは三流だ」と言われたのですが、今は令和ですよと言いたかったです。メモリを意識してプログラムを書く必要性を分かりやすく教えて頂けませんか？
回答 (25件中の1件目) 令和だろうがなんだろうが意識はしてないとダメだと思いますよ。 ハードウェア資源の限られた組み込み系やゲーム系は別として、業務系でもWeb 系でも 1バイトでも少なくなるように無駄を削るみたいなことはしなくてもいいでしょうし、たいていは解放漏れも意識しなくて良くなってます。 昭和〜平成初期のハードウェア/ ソフトウェア事情から考えれば、およそ足りなくなることが考えられないような大量のメモリーを使えはしますが、無限ではありません。 メモリー搭載量は予算次第で増減しますしね。 そして使えるメモリーの量よりも知識や想像力の欠如、考えなしのプログラミングからくる...
Pythonに上級テクニックは要らない（そして正しい付き合い方）～TechFeed Conference 2022講演より | gihyo.jp
TechFeed Conference 2022 Pick up Pythonに上級テクニックは要らない（そして正しい付き合い方）～TechFeed Conference 2022講演より 本記事は、2022年5月に開催されたTechFeed Conference 2022のセッション書き起こし記事「Pythonに上級テクニックは要らない（そして正しい付き合い方）（清原弘貴） — TechFeed Conference 2022講演より」を転載したものです。オリジナルはTechFeedをご覧ください。 Pythonに上級テクニックは要らない、そして正しい付き合い方ということで発表します、清原です。 株式会社ゼンプロダクツというのを最近立ち上げまして、日本語を書けばAIが文章を校正してくれる、Shodoというサービスを本気で作っています。Markdownでも書けて、はてなブログに配信で
AtCoder高橋社長がLINEのコーディング試験を見て驚いた理由―。「競プロとこんなに違うとは……」
ITエンジニア志望者にとって、時に「避けては通れない道」となるコーディング選考。実際に人気企業では、どのような試験や採点が行われるのだろうか。今回はLINE株式会社の協力の下、外資就活ドットコムの会員が参加（＊1）する模擬コーディング試験を開催。LINEが実際の選考で出すような問題を、参加者に解いてもらった。 その解答内容を題材に、LINEの新卒採用でコーディング試験を担当する大澤和宏さんと、特別ゲストのAtCoder高橋直大社長の対談を実施。2人の言葉から、「良い解答」「そうでない解答」の差、そしてコーディング選考と競技プログラミングの違いなどが見えてくる。【藤崎竜介】 ＊1 AtCoderで中級者とされる茶色もしくは緑色レベル、かつ2024年卒業予定の学生を対象に参加者を募集（AtCoderのランクについては、公式ページで詳細を確認できる） 〈Profile〉 写真左／高橋直大（たかは
読みやすいコードのガイドライン ―持続可能なソフトウェア開発のために
この本の概要 開発が大規模化・長期化するほど，コードを「読む」コストは増大していきます。そのため「読みやすさ」の向上は，生産性を改善し，プロダクトの成長限界を引き上げる重要な手段と言えるでしょう。 本書は，読みやすさの本質を学び，実践するための考え方をマスターできる一冊です。体系的な理解を実現するため，あらゆる角度から，豊富な例を交えて解説しています。表面的なテクニックではなく，いま目の前にあるコードに最適な改良方法を選び取る力が身に付きます。 こんな方におすすめ プログラミングの基本を学び終え，さらにステップアップしたい方 1か月以上かかる長期の開発に携わる方 コーディングのルールをどう適用するか知りたい方 はじめに 第1章 可読性の高いコードを書くために 1-1 生産性への恩恵 1-1-1 開発の規模と生産性の関係 1-1-2 可読性を高めるための環境と評価体制 1-2 可読性の高いコ
Rustで型レベルプログラミング
はじめに 通常のプログラムは実行時（ランタイム）に1 + 1など様々な計算を行う。一方でコンパイラーを持つ言語では、コンパイラーの型検査やジェネリクスなどの機構を利用して、コンパイル時にも計算を行うことができる。このようなプログラミングを、コンパイル時に検査・推論される“型”[1]に注目して型レベルプログラミングと呼ばれる。 ランタイムの計算の中にはたとえばwhile(1);のような簡単な計算で無限ループといった停止しない状況に陥いることがある。コンパイル時にできる計算でこのように無限ループに陥いってコンパイルが停止しなくなってしまったら、プログラムを実行することなく自明なエラー（型があってないとか、Rustであればfreeするタイミングが自明でないなど）を検出しようというモチベーションが崩壊してしまう。したがってコンパイル時にできる計算とはランタイムに比べて非常に限定された計算しか許可さ
クソコードと思わない - Mitsuyuki.Shiiba
なんか、あんまりいい感じじゃないなぁって思うコードに出会ったとして、それをクソコードと呼ばないようにはしてたんだけど、いつからか、そもそもクソコードだと思わなくなってる そのときの、そのコードが書かれた環境があって、それは、その人が持っているスキル以上のことをなんとかしないといけなかったのかもしれないし、めちゃくちゃなスケジュールの中でやらないといけなかったのかもしれないし、お試しで作ったものをそのまま使われちゃったのかもしれない あんまりいい感じじゃない構造だったとしても、そのコードによってシステムは動いて価値をもたらしていて、そのおかげで僕がそのコードに出会ってるんだから、それはとてもスゴイことだなぁって思う コードを悪者にして文句を言っても何も変わらないし、僕はエンジニアなのだから、そのコードをより良いコードにすればそれでいい 自分がコードを書くときには少し気をつけたり、あんまりいい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/Michigari/status/1636541366552637440
ロボット・プログラミング…「作りたい」子供集う場続々 - 日本経済新聞
