FortranとC++とコンパイラとYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
「実用的でないPythonプログラミング」がよかった - Stimulator
はじめに 2020/8/12に発売されたImpractical Python Projects: Playful Programming Activities to Make You Smarterの日本語訳書である、「実用的でないPythonプログラミング」をひょんな事から献本していただく事になった。（訳者が同僚である） 実用的でないPythonプログラミング: 楽しくコードを書いて賢くなろう! 作者:ヴォーン,リー発売日: 2020/08/12メディア: 単行本 ありがちなプログラミング初学者向けの本から1段上がった中級者向けの良い本だと感じたので、当ブログでたまにやっている筆者、訳者に媚びを売るシリーズの一貫として、感想を記す。 書籍の概要 「実用的でないPythonプログラミング」は、想定する中級レベルのアルゴリズムの問題を例に取り、Pythonでの美しいコードの書き方や、コンピュ
ノーコードは形を変えた現代のRPGツクールなのではないか
この記事について。 2030 年 「エンジニアです。コードは書けません。」｜__shinji__｜ note 自分はそもそもビジュアルプログラミングやオーサリングに興味があり、ノーコードは興味の範疇でありつつも、現状のもの、現状の「コード抜きで作れる」ような謳い文句は厳しいと思っています。それを、RPG ツクールを例に説明します。 はじめに、ノーコードを分類する 本記事では、「専用の管理画面で編集し、出力のためにコードを書かない、もしくはコピペ程度」のものをノーコードとして扱います。 その中でさらに種類ごとに分類してみます。このような定義があるわけではなく、自分の主観的で暫定的な分類です。 タイプ 1: データベースから自動的にフォームを生成 Google App Sheet MS Power Apps タイプ 2: 高水準 API のパイプライン Zapier IFTTT 古の Yaho
「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
Erlangについて思うところ
職場の今までいた部署が潰れてしまったので、新しい部署で仕事のためにErlangを学んでいる。基礎的な文法については学び終わったので、現時点でのErlangについての雑感を書いておこうと思う。 Erlangは多数派のプログラミング言語とはだいぶ違う文法を持っている。終端記号がドットであることもそうだが、比較演算子もだいぶ違っている。多くの言語が!=を使うなか、Erlangは/=を使っている。Less than or equal toが=<であるのも多数派とは異なっている。ただし、Greater than or equal toは>=だ。一貫性がない。 終端文字はドットだが、関数の中には一つの式しか書くことができない。式はカンマで区切ることができるので、以下のようになる。 func() -> expr1 , % カンマ expr2 , % カンマ expr3 . % ドット このような文法はリ
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
ウェブ魚拓
URL: https://note.mu:443/kotofurumiya/n/n31d401fce782 取得日時: 2019年1月2日 23:18 削除理由: 個人情報削除済み 手続日時: 2021年2月12日 19:20
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
PythonはJavaやC ++に比べて非常に遅いのに、なぜ機械学習のような高速アルゴリズム処理にPythonが使われるのですか？ - Quora
機械学習でPythonで行うというのは、Pythonで計算処理をすることではなくて、C++等で書かれた（Python向けの）の計算処理の外部ライブラリを使うことを意味しています。Pythonを使うのは簡単なデータの前処理や後処理（結果をログファイルに書き出すなど）だけです。メインの計算処理をPythonで書くことはありません。というか、Pythonはそもそも機械学習みたいな重い計算に用いることは全く想定されていない言語なので、メインの計算処理は書きたくてもPythonでは書けません。 こう書くとPythonは不便な言語だなと思われるかもしれませんが、実際には、深層学習などの、GPUや並列計算機をブン回すような重い計算を必要とするような処理は、JavaだろうがC++だろうが、基本的に、素人（機械学習の専門家は、普通、計算機の高速化(HPC)に関しては全くの素人です）が書いたコードは、遅すぎて
お薦めのコンパイラの本とか | κeenのHappy Hacκing Blog
κeenです。たまにお薦めコンパイラの本教えてなどのやりとりをTwitterで見かけるのでまとめておきます。 私の主観が入っているので他の方の意見も参考にして下さい。 普通の入門書三書 よく挙げられるのは通称「ドラゴンブック」、「タイガーブック」、「中田先生の最適化なんちゃらの本」です。 このうちのどれかを読むと良いでしょう。 こういう教科書系の本によくあることですが、本だけでなく挙げられている参考文献の情報も重要なので読み終わっても売らないで本棚に残しておくことをお薦めします。 コンパイラ[第2版]～ 原理・技法・ツール ～ いわゆるドラゴンブックです。結構古くからある本です。前半が構文解析の理論で、後半でコンパイラ関連の技法などが載っています。 割と技法の紹介が多く、幅は広いですがそれぞれの説明に割かれた紙面は小さいです。 章分けが雑なので目次だけで内容を判断せず、手にとって確かめたほ
“Rubyは死んだ”のか？ まつもとゆきひろ氏が語る「プログラミング言語サバイバル」とRubyの未来 - Part1
2018年12月14日、品川シーズンテラスカンファレンスにてRubyアソシエーションが主催するイベント「Ruby Business Users Conference 2018 Winter」が開催されました。すでにRubyを活用しているユーザーや、これからRubyをビジネスに活用しようと考えている人が集い、情報交換を行いました。基調講演「プログラミング言語サバイバル」に登壇したのは、一般財団法人Rubyアソシエーション理事長のまつもとゆきひろ氏。Rubyの開発をはじめて25年、今日のプログラミング言語の潮流とRuby開発者として感じている危機感について語りました。 プログラミング言語サバイバル まつもとゆきひろ氏（以下、まつもと）：どうもこんにちは、まつもとと申します。今日は「プログラミング言語サバイバル」というタイトルでお話をしようと思います。 今年は、2月にイベントをやりましたが、Ru
プログラミング教育は割と大丈夫かもしれない — 但しChromeが入れられればね。
先ほど、地元の小学校の6年生の全児童を対象に、プログラミングの「体験」授業をしてきた。受験シーズンで欠席がちらほらあったが、3クラスで合計90人ほどが参加した。放課後ではなく、正規の授業枠である。 CoderDojo仲間の田中さん。一緒に、授業してきた帰り道。対象とした小学校世田谷区の公立校で、今年度利用を開始した新校舎のため、インフラは恵まれている。渋谷区のように児童全員にPCがあるほどではないが、無線LANの速度などは十分と言えそうだ。 世田谷区の公立小学校Windows タブレットが全校で40台ほどWiFiの速度が15～50Mbps6年生のスマートフォンの普及率はかなり高そう (8～9割か) ※英語の分かる児童が1割くらい ※実は私の母校でもある。’90年当時、FM TOWNSが2台放置されていて、よく遊んでいたのを覚えている。30年経ってタブレットに替わり、一般教室でも使えるように
ま た 大 森 敏 行 か | おごちゃんの雑文
一連のCOBOLの話で、また日経BPがアホな記事を上げている。 COBOLは難しいか、記者が試しにコードを書いてみた まぁ努力は認めるが、間違いだらけである。で、記者を見ると、以前にクソ記事で私に叩かれた「大森敏行」氏である。 以前に叩いたエントリはこっち。 「悪い大人」 どうもこの人の傾向として、よく知りもしないことをよく調べもせずに、わかったようなことをわかったような文章で書くというのがあるようだ。てめーは自分が物事をよく知らないってことに謙虚になれんのか？ 細かい間違いを一々指摘するのは馬鹿げているので、大きな部分だけ挙げておく。 まず、題材を「FizzBuzz」に持って来たのが間違いである。 COBOLは「データ構造の扱い」を記述する言語であるので、「処理」を書くことはあまり得意ではない。この「得意ではない」というのは、出来ないとか表現能力が低いとかではなくて、 簡潔な表現が出来な
文系でプログラマーになったけど色々失敗して３年半で会社を辞めた話｜denkigai
このnoteをすべてのインターネット探索者(Internet Explorer)達に捧げる。 2018年12月31日、新卒入社して３年半勤めた会社を辞めた。東京の八重洲にある、フリーペーパーやWebサービスを作る会社で働いていた。いわゆる「文系プログラマー」というやつで、文系学部を卒業後、会社に入ってからプログラミングを覚えた。現在は退職してフリーランスになり、個人で開発しつつ、ずっと漫画を描いている。 3年半のあいだ、大きく分けて2つの失敗をした。 1. プログラミング入門の仕方に失敗した 2. プログラミングを覚えてから何をすればいいかわからなかった 前者の失敗の結果、プログラミングを投げ出して京都に逃亡した。後者の失敗では精神を病み、3ヶ月休職をすることになった。前者は笑い話だが、後者は人生に暗い影しか落とさない。これからプログラミングを始めようと考えている人には同じような失敗を避け
業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary
昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か
底辺IT企業は『書けない』プログラマとどう向き合ってきたか - megamouthの葬列
新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて（元エントリでは学生さんのようである。さもありなん）そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった？」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.bgu.ac.jp/assets/old/center/library/3251be657dadd73ca996d1174018c99a267336aa.pdf
｢この強いAIは何だ？｣オンライン麻雀の“謎”の答えは、マイクロソフト ──｢不完全情報ゲーム｣に強いAIは金融業界を変えるか
一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
