Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
This is tis-interpreter, an interpreter of C for detecting undefined behavior. tis-interpreter detects subtle bugs in C programs that may not have eye-visible effects when executing the same programs compiled in the traditional way. Some of the bugs that are discovered lead to security vulnerabilities. Fortunately, most don’t. tis-interpreter works by interpreting C programs statement by statement
あなたのお子さんは(あなた自身も)、コンピューターの画面にへばりついてゲームの世界をうろついている時間がどれだけあるだろうか。完全にピクセル化された街の中を。もったいない! そろそろ、その時間をゲームを「作る」ために使うべきだ。そこで、私の子どもが通う小学校で行っている、幼稚園児から5年生までの子どもたちにプログラミングを教えるという試みを紹介したいと思う。あなたも、これを読めば子どもたちにコーディングを教えてMakerの卵に育てあげることができる。 これは子ども専用というわけではない。誰であろうと、プログラミングを教える最適な方法だ。4歳から104歳までの誰もが、ちょっとの時間でテクノロジーのブラックボックスを開いて、未来はタブレットをいじる自分の指の先にあることを実感できるようになる。 12月のはじめ(12月7日〜13日はコンピュータサイエンス教育週間)に、Code.orgが毎年開催し
(訳注:2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、本当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars (忍者戦争)でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v
Your Ruby code smells. And it’s okay -- mine does, too! Maybe it has some long methods with too many parameters, a few classes that try to do too much, an uncommunicative name here or there. No codebase is perfect, but it’s worthwhile to be aware of its deficiencies and refactorings that could improve the state of things -- so let’s look at a few example code smells, potential ways to fix them and
def deploy(ip): copy('code/', ip + ':~/code', recursive=True) write_template('conf/config.py', ip + ':~/config.py') write_template('conf/crontab', ip + ':~/.crontab') write_template('conf/crontab', ip + ':/etc/apache2/httpd.conf') run_as_root('service cron restart') run_as_root('service apache restart') post('https://pingdom.com/api/2.0/checks', { 'name':ip, 'host':ip, 'type':'ping' }) タスクを実行するものと
概要 システム開発者にとって、地味に重要なスキルであるサンプルコードを書いて説明する力。 今までも重要でしたが、今まで以上に必要とされる機会が増えているように感じます。 ここ最近になって必要とされる頻度が増えてきたと思われる場面ですが、 チャットツール上でのコードに関するコミュニケーション プルリクエスト上でのコードに関する議論 技術情報の公開時に沿えるサンプルコード 技術ブログ Qiita ナレッジ管理システム上での技術に関する知識の共有 DocBase esa.io Qiita:Team 技術系 QA サイトでの質問 ja.stackoverflow stackoverflow teratail 自作のプログラム、ライブラリを公開する際の README BitBucket GitHub GitLab Web 上のツールを利用したコードレビュー ペアプログラミング中 などがあります。 太
学校で習うような物事をインターネット上で学ぶことは、将来的には不可避なことのように思えますが、 現状において、多くの人々はオンラインで効率的に学習をしているとは言い難いようです。 Sebastian Thrunも、数カ月前のFast Companyのインタビューでこのことを 認めています。 私はこの夏、高校生に教える傍らソフトウェアを作り、コンピュータがどの程度、人々の学習の役に立つかを検証してみました。 この投稿ではその夏について、つまり生徒がどのように学び、私が作ったソフトウェアがどの程度、 彼らの学習の役に立ったか、何がうまくいき、何がうまくいかなかったか、そして次に目指すべきところはどこなのか、 について書いていきたいと思います。 カリキュラム 今回の検証の実践の場として、 AP(アドバンスト・プレースメント:成績上位の高校生が受講可能な大学の科目)コンピュータサイエンス の講義を
新しい仕事やプロジェクトを始める時に、コードベースを一から作ることはめったにありませんよね。なじみのないコードと格闘するのは骨が折れますし、新たに取り込む情報の多さを考えると、気の遠くなる思いがします。Rubyを使っていた環境からNestoriaに移った私の場合は、新しいコードベースの学習に加えて、Perlまで勉強しなくてはならなかったため、二重の苦しみを味わいました。そんな私が、できるだけ短期間で生産性を上げるために使った7つの方法を紹介します。 謙虚になろう プログラミングと聞いて、真っ先に”謙虚さ”を思い浮かべる人はいないかもしれません。何しろ”傲慢”が プログラマの三大美徳 の1つに数えられているくらいですからね。そうは言っても、なじみのないレガシーコードに出くわしたら、あまりにも分からないことが多すぎて、何度もミスをしてしまう自分にきっと嫌気がさすでしょう。このような場合は、謙虚
http://www.se-radio.net/2009/11/episode-148-software-archaeology-with-dave-thomas/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 他人から引継いだコードを把握するのにどこから着手するかというテーマで、たまたまいくつかのエントリーを見かけました。「コードを読み切れないほど膨大にある。」「前任者、経緯のわかる人がいる/いない。」「ドキュメントがある/ない。」など様々な事情が想定されますが、全部まとめて主な声を拾ってみました。 謙虚な姿勢で臨むこと。そのコードベースがわかりづらいのは、書き方が悪いコードだからかもしれないが、自分がその専門領域の知識がなかったり、ベースにあるアルゴリズムが本当に複雑な場合もありうる。それを、全
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes from practicing; applying the theory over and over again, using feedback to get better every time. How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and ho
http://corner.squareup.com/2013/11/culture-fit.htmlSquareが一連のブログでエンジニアのインタビュープロセス、採用基準などについて公開しています。昨日発表されたViewfinderの買収も報道によると、サービスを取り込むというよりはNYに拠点を広げるタレントバイ(talent-buy: 優秀な人材の確保)のようです。買収金額は発表されてませんが、買収先のサービスが不要で人材だけを確保する目的の場合は、人数 x $1M(約1億円)が相場と言われてるので、数億円〜10億円程度の規模でしょうか。 さてインタビューに話しを戻すと、ベイエリアの企業のエンジニアのインタビューは丸1日かかるので、現在勤めてる会社を休まないと面接にいけないという話しはよく聞きますが、Squareも例にもれず、かなり時間をかけているようです。 インタビューは計5時間 「
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
よい本なので、他書と比較しながら再読していきます。短期集中連載のつもり。 1章 理解しやすいコード ここでは本書の根底となる「すべての原則が生じるテーマ」と「読みやすさの基本定理」について説明がされています。 コードは理解しやすくなければいけない。 コードは他の人が最短時間で理解できるように書かなければいけない。 『C++ スタイルブック (IT Architects’ Archive―CLASSIC MODERN COMPUTING)』の「はじめに」には次のように書かれています。 チームが成果を上げるには、誰もが、他の人の書いたコードを読んで理解できなければならない。 『Code Craft ~エクセレントなコードを書くための実践的技法~』1章「防御的プログラミングの技法」には次のように書かれています。 簡潔性よりも明瞭性を重視してコードを書く 簡潔ではあるのものの混乱を招くおそれのある
ペアプロで if-then-else 文が出てきた際、「これ、else if の順序、こっちの方が良くない?」というような会話をすることが時折ある。 どれも当たり前のものかもしれないが、「ああ、確かに」という反応があることもあるので、今日はそんな会話の際に出てくる視点についてまとめてみた。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } 条件式の結果がtrueになる確率が高く、「ノーマル」に近いものを上に書く。可読性が上がる他、特に2.で触れる条件式の判定に時間のかかる場合や、ループの最奥にある処理などのif-then-else文の実行される回数が極めて多い場合には体感レベルで実行速度にも大きな差が出ることもある。 Code Co
日頃より、アレスネットをご愛顧いただきまして誠にありがとうございます。 「ホームページサービス」のサービス提供は2016年1月31日をもちまして終了させていただきました。 これまで長らくご利用いただき、誠にありがとうございました。 今後も、皆様によりよいサービスをご提供させていただけるよう、サービス品質向上に努めて参りますので、何卒、ご理解いただけますようお願 い申し上げます。 <アレスネットをご契約のお客様へ> 後継サービスとして「userwebサービス」を提供させていただいております。 詳しくは、以下のリンクをご参照ください。 ▼「userwebサービス」のご案内 http://www.ejworks.info/userhp/alles/index.html 今後ともアレスネットをご愛顧いただけますようお願い申し上げます。 株式会社イージェーワークス アレスネット カスタマーサポート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く