Online Python Tutor - visualize, debug, get AI help for Python, Java, C, C++, and JavaScript
Online Compiler, Visual Debugger, and AI Tutor for Python, Java, C, C++, and JavaScript Python Tutor helps you do programming homework assignments in Python, Java, C, C++, and JavaScript. It contains a unique step-by-step visual debugger and AI tutor to help you understand and debug code. Since 2010, over 15 million people in more than 180 countries have used Python Tutor to visualize over 200 mil
最近のJavaScriptフレームワークの評価とか - albatrosary's blog
最近JavaScriptフレームワークについて色々指標のようなものを提示するブログが流行っているようだ。適材適所のもと、これは大規模向きとか小規模向きとか早いだの遅いだの。加え「gitなんか覚えなくたって死なない」とか、UXうえい！みたいな話だと思いきや内容がUIに限ったこととか。 一体最近のフロントエンドはどうなってるんだ？という雰囲気になってきましたので、少しメモ的に書きました。 JavaScriptフレームワークについて JavaScriptフレームワークの状況を見ると（フレームワークかライブラリかの議論は置いておき） DOM Web Components Virtual DOM に分かれます。JavaScriptフレームワーク初期の頃はDOMを直接操作するものが多く出現してきましたが、レスポンスなど扱いに難しい面もあり、他のアプローチが考案されました。それがWeb Compoent
Unixツールを作成するためのヒント | POSTD
現代のプログラマを取り巻く世界には無数の方法で組み合わされた、たくさんのUnixツールがあふれています。優れたツールは開発環境とシームレスに統合されますが、そうでないツールは使うたびに不満がたまっていきます。また、優れたツールはあなたの想像力次第でどんなものにも適用できますが、そうでないツールはあなたの開発環境で動かすためだけでも、あの手この手の対策を講じなければならないことがよくあります。 “One thing well” misses the point: it should be “One thing well AND COMPOSES WELL” — marius eriksen (@marius) October 10, 2012 “一つのことだけうまくやればいい”という考えでは目標に到達しない。”うまくいったものを、うまく組み合わせる”ことまで考えるべきだ 良い設計に必要なもの
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
Big Sky :: Rob Pike のプログラミングに関する5つの掟
« git で pull-request を clone する設定が覚えられないので alias 書いた。 | Main | Vim で peco する「veco」書いた。 » 掟1 プログラムが時間を費やす箇所がどこにあるのかは知り得ない。ボトルネックは意外な場所で発生するため後知恵で批判してはならないし、ボトルネックがどこにあるか証明出来るまではスピードハックを入れてはいけない。 掟2 測定しよう。測定し終えるまでは、さらにはコードの一部分が残りのコードの支配的な量とならないならばチューニングを行ってはいけない。 掟3 凝ったアルゴリズムは、n が小さいときに低速となり、通常 n は小さい。凝ったアルゴリズムは大きな定数を有する。n は頻繁に大きくなり得ることを知るまでは凝ったアルゴリズムを得てはならない。 (n が大きくなる場合であっても、まず掟 2 を行いなさい） 掟4 凝ったアル
SwiftのArrayがヤバくなくなった - Qiita
概要 思ったよりバズったので、いくつか加筆修正しました beta3でArrayの型指定の方法が変わったなーと思って眺めていたら、もっと根本的な変化がありました。 SwiftのArrayがヤバイなどで話題になってたやつです。 公式ドキュメント The Swift Programming Language 変更点 Array in Swift has been completely redesigned to have full value semantics like Dictionary and String have always had in Swift. This resolves various mutability problems – now a 'let' array is completely immutable, and a 'var' array is complet
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
GitHub language trends and the fragmenting landscape
A while ago, I wanted to get a little quick feedback on some data I was playing with, but the day was almost over and I wasn’t done working on it yet. I decided to tweet my rough draft of a graph of GitHub language trends anyway, followed later by a slight improvement. Trends over time, smoothed to make it a little easier to follow Much to my surprise, that graph was retweeted more than 2,000 time
モバイルAPIデザインのまとめ - ワザノバ | wazanova
Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアのAPI議論」で紹介しました。）とEtsyのPaul Wrightの講演のポイントをまとめてくれています。 1) スピード ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。 2) RESTが常にベストとは限らない 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ
毎日コードを書くこと - snowlongの日記
ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。（そして、うまく行かなかったら失敗したような気分だった。） 週末にいつも予定が空いている
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
iOS上で動作する革命的ものづくり環境「Pythonista 3」の魅力をとくと語る
iOS用のアプリは通常、開発アカウントを取得し、Macを使って開発します。 開発アカウントを取得するほどではないが、iOSデバイス上で何かやりたい処理がある、という人はいるでしょう。 あるいは、プログラム好きな人なら率先してiOSデバイス上でプログラミングをしたいと思うのではないでしょうか。 そうしたニーズに存分にこたえることができる、iOSデバイス上で動作する統合開発環境がPythonista 3です。 2016年9月21日に開催されたPyCon JP 2016で @equal_001 さんがPythonistaについて発表されていたのでご紹介。 Python支持者のことをPythonistaといいますが、アプリ名はそこから取ったんでしょうね。 正真正銘のPythonが内蔵されていて、ローカルで動きます。 [参考] Kazuhiro AbeさんはTwitterを使っています: 「インタプ
社内Haskellチュートリアルのススメ | GREE Engineering
こんにちは。インフラストラクチャ本部の竹辺(@beketa)です。 このエントリはGREE Advent Calendar 2013 12日目の記事です。 1. グリーでのHaskellプログラマ採用 Haskellを導入する企業が増えているようです。最近国内のメディアで紹介された事例だけでも Tsuru Capital様: http://itpro.nikkeibp.co.jp/article/Watcher/20131003/508622/ NTTデータ様: http://itpro.nikkeibp.co.jp/article/NEWS/20131126/520642/ の複数があり、すっかり実用的なプログラミングとして定着した感があります。 弊社でも2012年の中ごろから複数のプロジェクトでHaskellを使い始めており、昨年からは一部の商用サービスでもHaskellで開発したミド
重要なのはオブジェクト指向じゃないと思うんだよ - Line 1: Error: Invalid Blog('by Esehara' )
最近になって、オブジェクト指向がよくわからないという御仁とご一緒することになった。別段、それ自体が悪いことではない。確かに、その人の書いた、以前のコードというのはめちゃくちゃであった。当然のことながらif文は何十にも繰り返されているし、その中でネストが3つにも4つにも増えていくという恐るべきコードだ。そして、どうやら僕の前に、教えてくれた人がいるらしく、その人に「オブジェクト指向というのを教えてもらったから、もう少し上手く書けるようにになっている筈だ」ということを言っていた。 僕はそのことに、特段ケチをつけたいとは思わない。誰だって無知から始まる。僕もオブジェクト指向にとんちんかんなことを言って恥をかくことがある（もしかしたらこれからもね！）。無知が恥なのではなく、学ばない姿勢が恥なわけだから、僕はそういうのはいいなあ、と素直に思える。しかし、どうも僕は引っ掛かっていることがある。それをメ
一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )
とりとめのない話をメモがてら。 最近、コードを読むことが多くあるのだけれども、「このコードは一人で書いているな」という感想を覚えることが多い。もちろん、基本的にはコードというのは、物理的には一人で書くものであるのは間違いないのだが、たぶん、それとはまた別種のものだ。 僕がこの世界でメシを食う数年前に、PHPユーザーは他の言語を知らないから、他の言語の良いプラクティスを知らないという批判が議論を呼んだことがあるようだ。このさいPHPはどうでもよく、問題は「他の言語の良いプラクティスを知らない」ということだ。プログラミング言語というのは、そのときに共存しているお互いのパラタイムと関係している。例えば、最近ならJava8がOption型を導入しようとしているのは、やはり「関数型言語」というのが成熟してきて、その方法論が有益なものとして受け止められるようになってきたからだ。C++もラムダを取り入れ
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
altJS勉強会「Haxeすごいからみんな使え！」
Common Lisp製のテキストエディタにコントリビューションをしたので、その実装とかこぼれ話を発表しました。
『iOSアプリ開発 達人のレシピ100』という本を書きました - その後のその後
2013年に入ってから4ヶ月間、無職のありあまる時間をつぎ込み執筆してきた本が、ついに本日発売となりました。 バルセロナで観光もせず執筆し、その後は鎌倉のコワーキングスペースに毛布を持ち込み半泊まり込みで執筆し、企画当初は230ページの予定だったところを大幅超過して370ページも書いてしまったほどに気合いを込めました。 タイトルには『達人のレシピ』とありますが、もちろん著者が達人というわけではなく、掲載しているレシピが達人レベルの難しさ、というわけでもなく、私が提案した『iOSアプリ開発に役立つTips』という地味なタイトルに対していろいろな大人の方々の意向が加わってこうなった、というものです（カッコイイので大変満足しております）。 本の内容 ざっくり言うと、iOSアプリ開発まわりのTips集です。 概要紹介代わりに、『はじめに』に書いた内容を転載します。 iOS SDK がカバーしている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
厚切りジェイソン、NHKでプログラミング番組「可能性は無限大」
ssig33.com - プログラマの話