文系出身おじさんがプログラミング未経験からGASおじさんになるまで - paiza開発日誌
Photo by Matthew Keefe どうも、小松です。paiza（ギノ）では編集担当をしています。 今はエンジニアや企業のエンジニア採用担当にインタビューをしているほか、このブログの校正なども担当しています。 ごくまれにブログの記事も書いています。最近だとこの記事を書いたのは私です。 paiza.hatenablog.com この記事の最後にも後ろ姿だけ出ています。そしてそこにも書きましたが、こう見えて実はpaizaのプログラミングスキルチェックではAランクです。今はそれなりにプログラミングもできます。（スキルチェックについて詳しくはこちら） とはいっても、この会社に入るまではプログラミングなんてまるでしたことがありませんでした。そもそも文系出身ですし、大学を出てからは記者や編集者といった文系ど真ん中みたいな仕事しかしてませんでしたから、対極だと思っていました。 今回は、そんな自
“プログラミング言語Rust: 2nd Edition”の日本語版PDFを作成した - Qiita
はじめに https://doc.rust-jp.rs/book-ja-pdf/book.pdf プログラミング言語Rust: 2nd Edition1の日本語版PDFを公開しました！ 組版上のエラーなどを見つけたら気軽にIssueなどで報告してほしいです 改善してほしい点なども歓迎します！ 頃合いをみてrust-lang-jaに移すかも 移した 実はWeb版もあります！ https://doc.rust-jp.rs/book/second-edition/ HTML版のソースはhazamaさんのMarkdownからRustコミュニティがフォークしたもので、PDF版と同じものを参照しています GitHub Repository https://github.com/rust-lang-ja/book-ja-pdf エラー報告などをお待ちしています。 追記 アスキードワンゴさんから出版されま
コード埋め込み機能（β）用のフォントを作りました｜佐賀野 宇宙
どうも、ピースオブケイクでデザイナーやってる佐賀野です。 先日noteでコード埋め込み機能（β）が実装されました。 実は今回、このコード挿入機能にあわせてnote独自の等幅フォントを開発、実装しています。その名も「note monospace」。 この note monospace についてちょっとご紹介させていただきます。 開発の経緯 コード挿入機能の実装にある目処がたった段階で、note開発チーム内で「noteオリジナルの等幅フォントがあったら面白いね」という話が軽く持ち上がりました。 必須要件ではないのでそのままデバイス依存の等幅フォントを表示するだけでもよかったのですが、等幅フォントにチャレンジする良い機会には違いないので、土日を使って（半ば勝手に）プロトタイプを作成。その後、社内で見てもらい実装の許可をもらった後、隙間時間でブラッシュアップを続け、埋め込み機能と同時公開となりまし
Swift版リーダブルコード「関心の分離と単純化のためのSwiftコードの最適化」 #tryswiftconf | DevelopersIO
はじめに おばんです、今朝はWWDC17のジャケットを着てオレンジジュースを飲んで、西海岸を思い出してイキっていた田中です。 このエントリーはtry! Swift Tokyo 2018のセッション 「関心の分離と単純化のためのSwiftコードの最適化」(Javier Soto) のまとめになります。 講演内容 公式サイトより引用。 関心の分離は、コードが再利用されないときには時期尚早な最適化とみなされることがよくありますが、我々がコードが何をしているのかを理解することに対しては大きく影響します。Swiftにおけるこの実例を紹介します。 このセッションの要約 コードは書くよりも読む時間の方が長いので、可読性を高める必要がある Swiftはコーディングの原則(Coding Principle)との親和性が高い いくつかの具体例をコードとともに紹介します 紹介する例はTwitterのアプリをイメ
「書き直した方が早い」は9割のケースで間違いだった - 怠惰を求めて勤勉に行き着く
はじめに、本エントリは特定の企業、チーム、個人を指して書いたものでは一切ない。100%僕の個人的な経験から来ている。 さて、職業プログラミングに従事していると一度は「これ書き直した方が早いっす」とか言ったことある気がする。自分の場合、多くは歴史のあるレガシーコードを読んだときだ。思い返せば、自分がこう思ったときはほとんどそれは間違いであった。 「なんだこのコード…」 「これ何書いてあるか分かんないっす」 「うーんこれもう書き直した方が早くないっすか？」 この流れは非常に危険だ。 なぜならプログラムというのは本質的に書いてある通りにしか動かないからだ。ちゃんと読めば絶対に何を書いてあるかは分かる。 ここで安易に選んだ書き直しという選択は、自分が慣れ親しんだやり方でその部分をそっくり置き換えるというだけで、それは他人にとってあたらしい「これ何書いてあるかあるか分かんない」を生む結果にしかならな
「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama
自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの
Functional Programming in Swiftを読むために、すごいH本を読み終えた感想 - 卵は世界である
Functional Programming in Swiftを読むために、すごいH本を読み終えた感想
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
Swift Playgrounds - Apple Developer
Learn to code with Swift Playgrounds Swift Playgrounds is a revolutionary app for iPad and Mac that helps you learn to code and build apps using Swift, the same powerful language used to create world-class apps for the App Store. Engaging lessons and walkthroughs demonstrate the core concepts of coding and building apps as you write real Swift code in an interactive environment. Learn and explore
@fladdictさんのインタラクティブ・プログラミング勉強会で「手触りの作り方」を学ぶ | IDEA*IDEA
@fladdictさん（＝深津さん）が開催する勉強会に参加するようになって半年が経ったのでまとめてみます。すごく楽しい。 ■ これまでのあらすじ 「インタラクティブ・プログラミング勉強会 第1回 乱数 | fladdict」を見かける。 こ、こういうのが知りたかった！ということで深津さんに速攻連絡、「立ち見でいいので参加させてください！」と前のめりに頼み込む。 勉強会に初めて参加したのが2014年の年末あたり。THE GUILDの若手メンバーのレベルの高さや、「え、あの作品つくったのあなたですか！？」的なすごい人に萎縮しつつも勉強開始。 なんだかんだと毎回勉強会に参加。毎回、新しい発見があって楽しすぎる。 （周りのメンバーに比べるとまだまだですが）ようやく勘所っぽいものがわかってきたのでブログにまとめてみる（← イマココ）。 ■ 何の勉強会？ 上に紹介したブログでも紹介されていますが、イン
自然現象のシミュレーション Nature of Code をスクラッチでやってみる - Introduction ランダムウォーク - 僕は発展途上技術者
ドットインストールの @taguchi さんに教えてもらった「Nature of Code」がとても楽しくてはまっています。 » @fladdictさんのインタラクティブ・プログラミング勉強会で「手触りの作り方」を学ぶ で詳しく紹介されていますが、跳ねるボールとか、風にそよぐ木だとか、波といったような自然現象をどうやってコードで表現すればいいかを Processing で学んでいきます。 英文の HTML で無料で公開されていて、Introduction を読み始めたのですが、YouTube の動画で作者の Daniel さん自ら講義していて、これがハイテンションで面白いので今はもっぱらこちらを観ています。いまも風呂に iPhone 持ち込んで観てきたばかり。 学生のときにこんな講義に出会っていたら、もしかしたらこっち方面に進んでいたのかも、なんて思いを馳せながら聞いています。 ベクトルと
RedPen でわかりやすい技術文書を書こう | DevelopersIO
最近はブログを始めマニュアルや仕様書など技術文書を書く機会が多くなってきました。 技術文書はわかりやすさが重要だと思うのですが実際は書けていません。 どうしたらわかりやすい文書が書けるのだろうか？と調べていたら RedPen というツールを見つけたので早速試してみました。 RedPen とは？ RedPen とはプログラマや記者が規約に従って文書を記述するのをサポートしてくれるオープンソースのソフトウェアツールです。 プログラミングが規約に従ってコーディングされているかチェックするように、RedPen は自然言語で記述された入力文書の検査を自動化してくれます。 RedPen の特徴 設定が柔軟に行えます。（カスタマイズも柔軟） どのような言語で書かれた文書でも処理できます。（もちろん日本語も OK です） Markdown や Textile フォーマットで記述された文書をそのまま検査でき
全盛期のJeff Dean伝説 - Qiita
Jeff Deanとは GoogleのSenior Fellow. Googleの基盤となる分散システムのほぼ全てに中心的に関わり、圧倒的なエンジニアリング能力を発揮したらしい。あまりにも尊敬されているため、IT業界において全盛期のイチロー伝説のような破天荒なホラ話のネタにされている人。 日本語での紹介がなさそうだったので意訳してみました。 元ネタはこちら。多すぎるのでGoogle社員じゃない人には面白みがわかりにくそうなもの、面白みが被っていると私が判断したものなどは省いてあります。 NP問題 Jeff DeanがGoogleの採用面接を受けたときに、もしP=NPが成り立つとしたらどうなるかを問われて"P=0かN=1ですね"と答えた。試験官が笑い終わりさえしないうちに彼はGoogleのpublic keyを突き止め、private keyをホワイトボードに書き終わった。 Jeff Dea
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
