タグ

Programmingとprogrammingに関するWatsonのブックマーク (1,069)

  • 高速化プログラミング

    このサイトは管理者が仕事上、CAE(Computer Aided Engineering=コンピューターに支援された技術)ソフトウェアのソルバー開発をしている間に身に付けた数値計算のプログラムを高速化するためのテクニックを紹介するものです。 プログラムを高速化させるというと難しそうに思われがちですが、ちょっとしたことでプログラムを数倍高速化できたりするものです。高速化プログラミングができるようになるためには才能よりも経験が重要です。つまり高速化プログラミングのテクニックができるだけ知ることが高速化プログラミングへの一番の近道です。 ここに紹介された高速化プログラミングのテクニックを一度お読みいただければ、自然と誰でも高速なコードを書けるようになると管理者は信じています。 このサイトの構成を説明いたします。最初にプログラムの高速化の簡単な説明と管理者が使用したマシン環境をご紹介します。そして

  • オーバーフローが引き起こした面白いバグの話|Rui Ueyama

    一度聞いたら忘れられないような印象深いバグというものがある。僕は数値のオーバーフローと聞くと必ずこの2つのバグを思い出してしまう。どちらも面白いエピソードなのでちょっと紹介してみよう。 一つ目は、初代Civilizationにあったバグである。Civilizationは文明間で戦う戦略シミュレーションゲームで、チンギスハンとかエリザベス女王みたいなプレイヤーを選んで、世界制覇か宇宙開発競争での勝利を目指すというゲームだ。 初代Civilizationにあったバグは、非暴力主義のガンジーが突然核攻撃してくるというものだった。原因は文明が民主主義を採用すると攻撃性が2下がるというロジックだった。初代Civではガンジーの攻撃性は全プレイヤー中で最小の1なのだが、ゲームが進んでインド文明が民主主義を採用すると、攻撃性がマイナス2されてオーバーフローで255になり、ガンジーがゲーム中で突如、極度に攻

    オーバーフローが引き起こした面白いバグの話|Rui Ueyama
  • 読みやすいコード(僕にとって) - Mitsuyuki.Shiiba

    最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク

    読みやすいコード(僕にとって) - Mitsuyuki.Shiiba
  • 「プログラミングの常識」を時々見直す必要性について|Rui Ueyama

    自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上のの開いているページを見るのと、そのAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

    「プログラミングの常識」を時々見直す必要性について|Rui Ueyama
  • プログラミング言語について | POSTD

    最初に学んだプログラミング言語を覚えています。2年生のとき必須であった情報クラスの授業でBASIC言語を学習していました。暗い蛍光灯の下、前かがみに机の前に座りながら、空気のこもった教室の壁際に並べられ、音を立てているIBMパソコンを我慢できずに見ていました。時は1997年のロシアです。誰の家にもコンピュータはありませんでした。先生がチョークで汚れた黒板に下記のように書きました。 他のクラスメートのきょとんとした視線同様にそこに書かれた訳の分からない「暗号文」に8歳の自分も視線を注いでいました。先生は『恐れる必要はありません』と。安心させようとやわらかい口調で言いました。この日までの数週間、彼女に授業でフローチャートを書かされていました。この時点で、既にポテトの皮むきやレゴの組み立ての「アルゴリズム」を詳細に設計することができていました。それでも黒板から睨み付けるラテン文字は異質でした。

    プログラミング言語について | POSTD
  • ログイン - はてな

    パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。

    ログイン - はてな
  • 優秀なプログラマになるために - @ledsun blog

    みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは? おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや

    優秀なプログラマになるために - @ledsun blog
  • 『リーダブルコード』を現場で読み解く! 開発スピードを向上させる、読みやすいコードの書き方【今こそ読み解きたい名著】 - エンジニアHub|Webエンジニアのキャリアを考える!

    リーダブルコード』を現場で読み解く! 開発スピードを向上させる、読みやすいコードの書き方【今こそ読み解きたい名著】 圧倒的名著として知られる『リーダブルコード』ですが、高い評価には理由がある!現役エンジニアが、この一冊を読み込み、変数名の命名法など、読みやすいコードを書く極意とその必要性を抽出します。 数多くの開発者から支持を受け、読み継がれてきた名著。そこには読み継がれる理由があります。 名著には、内容・ボリュームともに充実した書籍が多く、概要に目を通しただけでを読んだつもりになっていたり、腰を据えて読む時間がなく「積ん読」してしまいがち。「エンジニアが絶対読むべき書籍●選」といった記事をブックマークするだけで読んだつもりになっていないでしょうか。 ポイントを押さえつつ内容を深掘りし、名著の根底に流れるエッセンスを開発に活かしましょう。 アプリエンジニアの池田惇(@jun_ikd)で

    『リーダブルコード』を現場で読み解く! 開発スピードを向上させる、読みやすいコードの書き方【今こそ読み解きたい名著】 - エンジニアHub|Webエンジニアのキャリアを考える!
  • 良いエラーメッセージの書き方 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    良いエラーメッセージの書き方 - Qiita
  • misspell - ソースコード専門のスペルミスチェッカー

    MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 英語圏に住む人であっても英語のスペルミスをします。むしろ日人が日語で文章を書くように、普段ずっと英文を書く中ではスペルミスがたくさんあるでしょう。コードの中でもそんな発見は良く目にするのではないでしょうか。 今回は特にソースコードに特化したスペルミス発見器、misspellを紹介します。 misspellの使い方 misspellはコマンドラインで使えます。ファイルまたはディレクトリを指定するだけです。 $ misspell Blog/ 8.md:19:68: "currenty" is a misspelling of "currently" 2.md:217:34: "unneccesary" is a misspelling of "unnecessary" この手の多く

    misspell - ソースコード専門のスペルミスチェッカー
  • 入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング

    実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす

    入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
  • コードレビューをより効果的にする方法

    ツールに任せることができないどんなことを人間は指摘できるのだろうか? 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか? コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか? 新しいコードでデザインパターンは使用されているだろうか?これらは適切だろうか? コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか?コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか? コードは正しい場所に配置されているだろうか?例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか

    コードレビューをより効果的にする方法
  • 一日8時間、60日間ペアプロしてみて思った日常ペアプロのコツ. 一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミン… | by Naohiro Oogatta | Medium

    一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミングで新規アプリのクライアントからサーバまで開発してみました。チームにエンジニアがちょうど二人だったので。 もはや日常がペアプロです。ペアプロ以外でやってるのは簡単なバグ修正やちょっとした環境整備で、あとはすべて二人で開発しています。ちなみにまだまだ続いています。狂気です。 いい大人が二人集まって狂気を選ぶことになったわけは、成果も出てないしまだ書けません。でも今って、ペアプロやモブプロがブームだって聞きました。それじゃあアホみたいにやってる人間としては黙ってられないです。基的なことはおいといて、とりあえずこれだけはってつくづく思ったのとか、ペアプロを有意義に長く続けるコツをまとめてみました。 (ちゃんとした話は ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Program

    Watson
    Watson 2017/07/21
    コミュ障なので、こんなの死ねるかもしれん( ˘ω˘)
  • コードレビューの極意。それは「自分のことは棚に上げる」こと!! - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに:コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん!って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、

    コードレビューの極意。それは「自分のことは棚に上げる」こと!! - Qiita
  • Webデベロッパのためのセキュリティ・チェックリスト | POSTD

    安全で堅牢なWebアプリケーションをクラウドで開発するのは 非常に困難 です。それを簡単だと思っているような人は、例えばとんでもない頭脳をお持ちというなら別ですが、遠からず痛い目を見ることになるでしょう。 もし MVP(Minimal Viable Product:必要最低限の機能を備えた製品) のコンセプトを鵜呑みにして、有益かつ安全な製品を1ヶ月で作成できると考えているようなら、プロトタイプを立ち上げる前に一度考え直した方がいいと思います。以下に挙げたチェックリストをご覧いただければ、セキュリティに関するクリティカルな問題の多くをスキップしていることが分かるはずです。あるいは少なくとも、潜在的なユーザに対しては 誠実 であるように心がけ、製品が完全ではないこと、そしてセキュリティが不十分な製品を提供していることを伝えるようにしてください。 このチェックリストはシンプルなもので、決して完

    Webデベロッパのためのセキュリティ・チェックリスト | POSTD
  • コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD

    私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える!」的な投稿ではありません。記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注:私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報:記事が r/p

    コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD
  • Nintendo Switchにプログラミングツール「FUZE Code Studio」が登場、Switch上でスイッチ用ゲームを作ることが可能に

    好調なスタートを切ったNintendo Switchは、2017年6月14日に開催した「Nintendo Spotlight: E3 2017」の中で今後発売予定の新作タイトルを続々発表しました。しかし、この発表で紹介されたゲームタイトルは今後Nintendo Switchで登場する予定のゲームのごく一部であり、「任天堂に取り上げてもらえなかった興味深いゲーム」も多数存在しています。さまざまなプラットフォーム向けにプログラミングツールを開発しているFUZEの「FUZE Code Studio」もそんなゲーム(?)のひとつで、Nintendo Switchでプログラミングができるようになるというツールになっています。 FUZE Code Studio for Nintendo Switch http://www.fuze.co.uk/nintendo-switch.html Fuze Cod

    Nintendo Switchにプログラミングツール「FUZE Code Studio」が登場、Switch上でスイッチ用ゲームを作ることが可能に
  • P言語の素晴らしさについて - kuenishi's blog

    先週Microsoft社がP言語に関するブログ記事を公開し一部界隈で話題となった。 P言語くん pic.twitter.com/uULzxIO4ct— Kuntaro Ishiyama (@_iamkuntao) 2017年3月26日 「いまさら一文字言語かよ…」「何個目だ?」といった批判的諦念的なものから、「RustGoとErlangの間の子みたいなのだなあ」「なんか読みにくい」といった反応が多くこの言語の重要性やインパクトに対して正しく理解しているものがあまりなかった。尊敬しているTD勢ですらあまり重要性が伝わってないようだ 1 2 。上記のブログ記事を読んだり、マニュアルを読んだらすぐ分かるようなことではあるが、日語で解説しておこうと思う。なおいわゆる言語入門とかそういった類のものではないことをご理解いただきたい。 TL;DR 並行処理や分散システムの形式証明や形式検証はそれ自体

    P言語の素晴らしさについて - kuenishi's blog
  • 「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさの技術ブログは今か無しか

    土屋はプログラマの中でもかなりコメントが多いタイプだと思っています。理想を言えばコード1行ごとにコメントを書きたいくらいです(当は、識別子を全部日語で書きたいと思っているのですが、これはまた別の話)。 これは土屋がPDL(Program Design Language https://www.gamedev.net/resources/_/technical/general-progra... )開発スタイルの薫陶を受けているからなのですが、それとは別に「そもそも日人には英語ベースのソースコードを高速に読解するのは無理がある」と考えているからです。 また、より質的な課題があると思っていて、プログラミング業界的には「コードがドキュメントであるべき(≒正しく実装されたコードであれば、コメントは最低限になる)」という風潮がありますが、土屋は、これはプログラマが夢見る幻想に過ぎず、「質的

    「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさの技術ブログは今か無しか
  • 66歳からプログラミングを始め、自作の罠で年間90頭の猪を狩る猟師がいるらしい | Tech2GO

    更新日: 2017年09月26日公開日: 2017年05月18日66歳からプログラミングを始め、自作の罠で年間90頭の猪を狩る猟師がいるらしい こんにちは!Tech2GO編集部の岸です! 皆さんは「猟師」と聞いてどんな印象を持っていますか?「田舎」「銃を撃って鹿や猪を狩る」「当に猟師なんて存在するの?」などでしょうか? 実は私も滋賀県で猟師として活動しながらメディア「Tech2GO」にて勤務しています。猟師がIT系の会社にいるなんてびっくりですよね。ちなみに普段僕は鹿を狩っています。 ↓こんな感じです。 そんな、普段出会うことの少ない猟師が「Ichigo Jamを使った獣用の箱罠を自作」し成果を上げていると聞き、シニアプログラミングネットワーク #1に登壇されるとのことで滋賀から東京まで行ってきました! 「ichigojam」とは、子供向けの安価なプログラミングが可能なパソコンのこと

    66歳からプログラミングを始め、自作の罠で年間90頭の猪を狩る猟師がいるらしい | Tech2GO