Rust製の高速コードエディター「Zed」がAIコーディング支援「GitHub Copilot」に対応／マルチプラットフォーム対応には大きな進展はなし
O(オー)と0(ゼロ)など紛らわしい文字が見分けやすくなるプログラミング用の無料フォントをまとめた「Programming Fonts」
文章を読むのが人間であれば、入力にミスがあっても簡単に気付いて正しく読むことができますが、コンピューターにはそうした柔軟性がないため、プログラミングを行う際には一言一句正確に文字を入力する必要があります。この時に問題になってくるのが「O(オー)と0(ゼロ)」や「I(アイ)とl(エル)」など「人間には同じに見えるのに内部的には違う」文字で、これらの打ち間違いを目で探すのは至難の業。そんな紛らわしい文字をパッと見分けやすくしたプログラミング用のフリーフォントが「Programming Fonts」にまとまっていたので、どんなものがあるのか確かめてみました。 Programming Fonts - Test Drive http://app.programmingfonts.org/ サイトを開くと下のような画面になります。左から見たいフォントを選ぶと右のサンプルコードが選んだフォントで表示され
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub｜Webエンジニアのキャリアを考える！
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴（Yugui）さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント（=ソースコードに書かれている注釈やメモ）です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴（Yugui）さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴（そのだ・
「あるエンジニアがプログラムを紡いでいく様を見てみる」ライブコーディング・リプレイ - 日々常々
あるエンジニアがプログラムを紡いでいく様を見てみるでしたライブコーディングで言ったことや言わなかったことを書いてみます。 意識してるのは「コードをどまんなかに」です。 speakerdeck.com ……あ、このスライドのブログ書き忘れてた。 スライド中の「えらぶ」はだいたいIDEの機能を指します。なのでライブコーディング中に使用したIDEの機能も挙げようと思います。基本的にデフォルトのつもりだけど、vimとの兼ね合いで変更してるのもあるので、そこはごめんなさい。あとMacです。今回はメソッド抽出とかクラス間移動とかダイナミックなのがなくて地味だけど、便利な子たちなので使ってあげてください。 リプレイ 今日の公開コーディングはスゴい新鮮だった🎵 コミット後のソースには、どこに悩んだのか、どこにこだわったのかは残らないのですね。 実際のコーディングを見させて頂く事で、気づかされる事が多かっ
年収に効く要素とは何か
Getting Started年収を表現するには様々なものから予想する必要があります。 新卒での就職や、中途での就職にはどのような方法で選ぶのでしょうか。 働き方などもあると思いますが、一つ重要な要素として年収（給与）の大きさがあるかと思います。 DoDaさまという転職サイトには大量の求人が記されており、この説明文から給与を予想することで、どのようなことが年収に影響をおよぼすのか、定量的に確認していきたいと思います アルゴリズムElasticNetを利用します。単語ごとに重みをつけるBag of Wordsを利用しようと思います 精度自体はさほどではないですが、解釈性がよいので、見通しが立てやすく、LassoとRidgeの双方の正則化項を利用します(ゴミみたいな情報が多いので正則化項は重要です) 予想精度自体はGBMやDeep Learningのほうが当然いいのですが、解釈を求めていきます
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
クリエイティブコーディング学習の最適解としてのProcessingと，デイリーコーディングのススメ - 日常の進捗
これはProcessing Advent Calendar 2017 - Qiitaの21日目の記事です。 Advent Calendarを通じて「プログラミングを通じて個人が表現する文化」がもっと盛り上がったら良いなと思ったので，思い立って勢いで書いてみることにしました．このエントリの内容は大きくは以下の2つです． クリエイティブコーディング環境として，Processingは日頃のアイデアを形にしたり，プログラミングの基礎であるアルゴリズムを学ぶ道具として最適 決まった時間で短いコードでも良いから毎日書く「デイリーコーディング」は日々の成長が感じられてオススメ Processingで具体的に何か作ったものを紹介するというより，作るための取り組みとして毎日コードを書く習慣や，そのために出来ること（参考になる情報の紹介やモチベーションの維持など）について紹介できればと思います． クリエイティ
Hack - ソースコードのためのフォント
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました プログラミング用のフォントは何を使っているでしょうか。すでに世の中にはたくさんのフォントがあるので、好みによって千差万別でしょう。しかし見やすいフォントであれば文字の識別も容易になってバグも減りますし、何より書いていて快適です。 今回はそんなプログラミングフォントの一つ、Hackを紹介します。 Hackの使い方 こちらがHackの14ポイント。 個人的に好きなRickyの14ポイント。 Hackの方がRickyよりも太めで、文字がはっきりしている印象です。Hackは単純なアルファベットだけでなく、1500以上の文字が設計されています。ギリシャ語なども含まれるとのことです。また、ダウンロードだけでなくWebFont版も提供されています。 HackはOpen Font Licenseの
pythonで小さなツールを作る時のtips - Qiita
自分で小さいツールを作る時に心に留めているtipsです． 書き始めたときは「どうせ書捨てだし」と思って書き始めると意外と長い間，もしくはいろんなところで使うことになったりするので，気をつけておくと後から楽になるというような小技です．大規模なソフトウェアの開発ではまた違った流儀があると思います． メインルーチンを関数にする 関数名はなんでもいいのですが，自分は趣味で main() という名前の関数を用意し，メインルーチンは全てそこに書くようにしています． #!/usr/bin/env python def main(): print('hello, hello, hello!') if __name__ == '__main__': main() pythonの小さなサンプルコードを見たりすると関数外の部分にベタで実行コードが書かれていたりします．もちろんそれでも動くのですが，以下の2点で後
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
Naming -名前付け- - Qiita
プログラミングで最も重要な技術の一つが、名前付けです。 且つ、センスが問われるものなので、上達は難しいものでもあります。 この記事では、様々な文献から抽出した名前付けに関する情報を雑多にまとめました。 -名前重要- ソフトウェアの設計のアプローチとして、『まず名前から入る』というのは、あまり語られていない秘訣としてもっと広く知られても良いように思います。 - まつもとゆきひろ 『プログラマが知るべき９７のこと』 コミュニケーションの基礎 名前は、コミュニケーションの基礎となるものです。 私にもあなたにも名前が無ければ、疎通することは困難になります。 名前をコミュニケーションの基礎と見た場合に重要なルールは以下の通りです。 発音可能であること 検索可能であること ※現実世界のみであれば検索可能じゃなくても良いかも知れません。 プログラミングは、チームや複数人で行うことのほうが多いと思います。
最良のエンジニアは速記者ではなくアーティストだーーPaul Ford氏の大作記事「What is Code」が語ること - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
image via. Flickr <Pick Up> What I learned by reading Businessweek’s incredible 38,000-word article on code ライターでプログラマーのPaul Ford氏が書いた「What is Code」という記事が注目を集めてる。コードについて、専門家ではなくても理解できる形で語るこの記事は、38,000語から成る超大作。ピックアップした記事の著者は、完読するのに82分かかったそう。 実際の記事を読むに越したことはないけれど、時間がない人のために大事なポイントが要約されていたので、一部をご紹介します。 あらゆるものを動かすのはソフトウェアだーーWindowsやFlappy Birdに限らない。銀行のATM、エレベーター、洗濯機、わたしたちの生活のあらゆるものを動かすのは、その裏側にあるソフトウェア
プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ
僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか？」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.vivi-life.com/entry/2018/02/17/205006
【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised
TechCrunch | Startup and Technology News
CSS, jQueryからPython, Rubyまで、制作者の困ったを解決するコードのスニペットを共有する無料サービス -Code Pad
