京都大学、Pythonの基本を解説した無料の教科書「素晴らしすぎる」「非常にわかりやすくて良い」 | Ledge.aiTop > ラーニング > 京都大学、Pythonの基本を解説した無料の教科書「素晴らしすぎる」「非常にわかりやすくて良い」
算数の教養がほとんどないプログラマが1年間AtCoderをやった結果の振り返り｜きりみんちゃんノート
こんばんみんみん。 バーチャル幼女プログラマーという肩書でインターネットをやっているきりみんちゃんというものです。 去年の7月に競技プログラミングのAtCoderを始めてだいたい1年くらい経ったので、勉強したこととかを振り返りたいと思います。 で、誰？YouTubeでAtCoderの過去問を解く配信をしたり、Twitterで無限にAtCoderについてつぶやいたりしているVTuberです。 普段の仕事での専門分野はAndroidアプリ開発です。 半年くらい前にAtCoderを普通の社会人エンジニアに布教するエントリを書きました。 また、技術書典で「AtCoderの歩き方 -数学が得意じゃないエンジニアにこそ競技プログラミングを布教したい！-」という本を出したりもしました。 現在のAtCoderコミュニティの中心層は理系の学生やもともと数学がかなり好きなタイプの人たちです。 一方きりみんちゃ
京都大学が無償公開したPythonの教材がわかりやすいと話題に : IT速報
京都大学は、Pythonによるプログラミング演習の教材を無償公開した。 プログラミング演習の教材は、プログラミングの初学者を対象にPythonを用いたプログラミングを演習方式で学ぶもので、京都大学学術情報リポジトリ（KURENAI）で公開されている。本編のほか、横道にそれる話題をまとめたコラム編の2つの教材がある。著者は国際高等教育院 教授の喜多一氏。 本教材は、2018年度に全学共通科目として実施された授業を元に構成されたもので、到達目標としては以下の3つを挙げてい… 続きはソース元で https://codezine.jp/article/detail/11999 https://repository.kulib.kyoto-u.ac.jp/dspace/handle/2433/245698
お前は絶望的にプログラミングに向いてないから諦めて刺身にタンポポ乗せる仕事でもやってろ｜古都こと｜note
刺身にタンポポ乗せる仕事ってきょうび言わねーな……。 プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…！」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。 近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。 開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のもの
ぼくはこうしてプログラミングを覚えた
オリジナルはココです。フェイスブックのエンジニアで史上ベスト３に入るといわれるEvan Priestley氏への質問「どうやってプログラミングを覚えましたか」に対する本人からの答えです。 手短かに言えば 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、（フェイスブックで働いていた）過去４年間、ほとんど他のことをしていない。その前も２.５年ほどプログラマーとして働いていたし、そのさらに前も６年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで（最初はMac Plusで途中からIIsiになった）で散々遊んだ。８歳か９歳の
引数の型を何でも List にしちゃう奴にそろそろ一言いっておくか - Qiita
この記事は C# その２ Advent Calendar 2018 の第一日の記事である。 はじめに この記事では、主にエンタープライズアプリケーション（SI、企業向けの業務システムやパッケージ製品）の開発に於いて、新規開発ではなく修正や拡張を行うようなシーンを想定して、無駄な工数をなるべく削減すべく自分なりに考えて実践しているベストプラクティスを書いている。 新規開発の場合でも、将来の拡張や修正が見込まれるはずなので、考慮すべき事は同じだ。 競技プログラミングや、組み込み開発の場合でも基本的な考え方は適用可能だが、メモリ効率やパフォーマンスを考慮する必要もあるので、あえて配列を使ったり、逸脱するようなケースもあるだろう。 対象とする読者層は、C#プログラミング歴1年以上、SIer やユーザー企業に所属（もしくは常駐）し、特に複数人チームでの開発に携わる若手プログラマ、初級から中級へのステ
13年分の未熟なゲームのコード | POSTD
1人きりの金曜日の夜、何らかのインスピレーションを求めていた私は、以前のプログラミングのいくつかを再現することに決めました。 昔のハードドライブがゆっくりと回転し、栄光の日のソースコードが表示されます。 しかし、蓋を開けてみると、全く期待していたものではありませんでした。”ここまでひどかったのか。なぜ誰も言ってくれなかったのだろう。なぜ自分はこんなにひどかったのだろう。 1つの関数内に、これほど多くのgoto文をよく入れられたものだ。 “ 私はすぐに自分の試みを諦めました。そして一も二もなく、コードの削除とハードディスクの完全消去を考え出しました。 以下は、過去の自分を見ることで得た教訓や断片、警告などをまとめたものです。過去の過ちをそのまま公開するためにも、名前などは変更していません。 2004年 私は13歳でした。このプロジェクトは Red Moon という、野性的で野心的なサードパー
全ての開発者が学ぶべき5つの言語 - Qiita
「どの言語を学ぶべきか」という議論はエンジニア向け記事の定番ネタですが、HackerNoonに投稿された5 Programming Languages Every Master Developer Should Learnという記事がなかなか興味深かったので翻訳してみました。 (2018/11/04追記) こちらの記事に関する「別視点からの意見」として下記のような記事を追加いたしました。宜しければこちらも併せてご参照ください。 Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 はじめに 「プログラマーは新しい言語を毎年1つは習得するべきだ」という趣旨の文章をどこかで読みました。(多分CODE COMPLETEだったと思いますが) もしそれが難しくても、キャリアの中で最低限この後に紹介する5つの言語に通じておくことをお薦めします。 あらゆる会社は、多言語を
増田式プログラマー養成講座 コンテンツ一覧
コンテンツが増えてきたので、一覧ページを用意します。 第1章 準備anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意 anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類 第2章 手続型言語 2-1 構造化プログラミングanond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐） anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習 2-2 オブジェクト指向プログラミングanond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？ anond:20181017191404 増田式プログラマー
競技プログラミングで黄色になるまでにやったこと - hogecoder
先月末に、めでたく AtCoder 黄色になりました。 1976 -> 2025 (+49) 念願の！！！！ 黄色！！！！ です✌️✌️✌️✌️✌️✌️✌️ pic.twitter.com/6S5whNlq8G— tsutaj (@_TTJR_) 2018年9月29日 きのう、ふと「黄色になりました記事書いてないなぁ」と思って雑に呟いたら、書いてくれという圧力声援を感じたので、記していこうかなと思います。記事の特性上自分語りしかありませんが、それでも良い方はお読みいただければと思います。 自分の能力について やったこと 灰から茶へ 茶から緑へ 緑から水へ 水から青へ 青から黄へ 最後に 自分の能力について 世の中には、プログラミングを始める前から数学が大得意で、 AtCoder を初めて半年くらいで黄色になるような「競技プログラミングをするために生まれてきた天才」*1も中にはいるのですが、
ググるのをやめるとプログラムの生産性が上がるかもしれない - メソッド屋のブログ
今日はプログラミングの生産性に対して気づきがあったのでシェアしてみたい。 なぜ米国の人は生産性が高いのだろう プログラミングの生産性に関しては以前から興味がありいくつかのポストで考えたことをシェアしてきた。私は職業柄、いろんな国でいろんな人々とプログラミングを一緒にする機会が多い。その時に頻繁に感じるのは、平均的に言うと、アメリカの人プログラマが生産性が高い確率が高くて、しかもコードもきれいだという傾向にある。アメリカでお客さんと一緒にコードを書くと、お客さん自体が物凄く良く知っているし、実行力もある。アメリカの次と言うことでいうと、英語がネイティブの国もそれに近く、フランスなどの言語が近いところが続く感じなので、英語が物凄く影響すると思っていたし、実際すると思う。そのあたりの話はこちらのポストに書いてみた。 simplearchitect.hatenablog.com 定義での理解と、例
凄腕エンジニアの「錯覚資産」の使い方 - ゆとりずむ
こんにちは、らくからちゃです。 プーアール茶を片手にのんびり仕事をしていることが多いんですけど、中国茶はお湯を注いで最初の一杯目は捨て、いわば二番煎じから頂くんのが美味しいんだそうな。なんでも最初の一杯で茶葉を開かせ、コップを温めておくことが目的だそうなんですけど、物事によっては二番煎じ、三番煎じのほうが丁度よいくらいの頃合いになるものもあるでしょう。 人によっては「もう何杯目やねん」と思われるひとも居るかと思いませんが、ここ最近話題の「エンジニアはプライベートの時間でも勉強をすべきか」問題について、個人的に考えたことを整理しておきたいと思います。 axia.co.jp まずは結論を申し上げますと「プライベートでも勉強するかどうかより、業務時間中に上手に勉強時間を確保できるかどうかが重要なんじゃないの」と思うんですね。 つーか、エンジニアなら ・上司の目を盗んで ・上司を上手に騙して ・上
プログラミング勉強を加速させる7つの習慣 - Qiita
※ 本記事は自分が運営するブログに転載しています 株式会社LITALICOでWebエンジニア（Rails）を担当しています、@YudaiTsukamotoです。 この記事は『LITALICO Advent Calendar 2016』16日目の記事です。 はじめに 私は学生時代は情報工学の専攻でもなければ、趣味でプログラミングをやっていたわけでもなく、 社会人になってWebエンジニアとして初めてまともにプログラミングを勉強し始めました。 入社するまでに独学で勉強の真似事をしてはいましたが、そもそもどうやって勉強していいのか全然わからず、 本を読んで写経をして何故だか理由はよくわからないが動作してしまうミニブログを眺めては、ため息を付いて挫折を繰り返しておりました。 そんな初心者だった自分が、Webエンジニアとして食べていくために本気で努力して身につけたノウハウを、 「プログラミング勉強を加
メタファーを身につけてプログラミングの生産性を向上させる - メソッド屋のブログ
インターナショナルチームでプログラミングの仕事をしていると、いろんなところで同僚との差を感じてしまう。いろんな国の人がいて、レベルは人によりそれぞれなんだけど、一般的にいうと、アメリカのプログラマのレベルは平均してとても高い場合が多い。とにかくコードがきれいでシンプルで仕事が早い。 彼らがなぜそれができるのかを観察しているが、一つ気が付いたことについてその対策も含めて書いてみたい。 彼らがプログラマとして優れているところ USにいるとお客様の技術レベルが高いとか、新しいことにチャレンジするとかいろいろ要素はあるのだけど、個人の生産性、コードの美しさをみても、平均値を観察するとアメリカの人が一番に感じる。その他にも、ドキュメントを見てすぐ理解できる能力は、アメリカの人はおろか、ヨーロッパ圏やインドの人と比べても、私は圧倒的に負けていると感じる。 Williams 衝撃の読解力 新しいライブラ
［速報］AIがコードのレコメンドやバグの指摘など開発を支援してくれる「Visual Studio IntelliCode」発表。Build 2018
［速報］AIがコードのレコメンドやバグの指摘など開発を支援してくれる「Visual Studio IntelliCode」発表。Build 2018 マイクロソフトは、米国シアトルで開催中のイベント「Microsoft Build 2018」で、AIを用いてプログラマの開発を支援する「Visual Studio IntelliCode」を発表しました。 Announcing Visual Studio IntelliCode - Enhancing everyday software development with the power of #AI across the entire development lifecycle. See what’s coming: https://t.co/k5eaYWcfnM #VS2017 #VSIntelliCode pic.twitter.co
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
オブジェクト指向がわからない！ そんなあなたの脳味噌をオブジェクト脳にする準備体操
オブジェクト指向で挫折しないために オブジェクト指向のプログラミング言語は当たり前の存在になり、たしかに目新しさはなくなりました。業務でオブジェクト指向のプログラミング言語が使っている方も多いと思います。 だとすれば、そもそもオブジェクト指向とはどういうもので、実際のプログラミングでどう役立つのか、特別に学ばなければならないようなものなのでしょうか。 考えてみてください。たとえRubyやJavaを使えているとしても、オブジェクト指向プログラミングができているとは限らないのです。Rubyを学び、Railsの本を読んで自動生成されるコードを書き換えることはできても、自分でクラスを追加することができない方もいるかもしれません。 Ruby、Java、Pythonといった個別の言語を学習すると、どうしてもその言語の特徴や機能を中心に学ぶことになります。オブジェクト指向は技術書を読む前提知識として扱わ
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リファクタリング 目的・パターン・思考 / reprotech
http://www.vivi-life.com/entry/2018/02/17/205006
