プログラミング言語AWKのここがLOVE
プログラミング言語AWKが好きなので、この言語のどこが好きかを語ります。主にAWKを知らない、知ってるけど使ったことが無いかた向けの記事ですが、使ったことがあるかたも「こういう思いで使ってる人がいるのか」と遠巻きに眺めてもらえればと考えます。また、後半で最近出たAWKの書籍についても紹介しているので、そちらも役立つかもしれません。 AWKとは AWKは1977年にAT&Tベル研究所で生まれたプログラミング言語です。AT&Tベル研究所といえばUNIXが生まれたところです。著者もUNIXに縁が深い、この世界のレジェンドばかりです。たとえばKernighan先生はプログラミング言語Cをはじめ、たくさんの書籍の著者として有名です。なんだか強そうな言語ではないかという気がしてきました。 AWKは汎用プログラミング言語ですが、「1行1レコードになっているテキストファイルを最小の手間で処理するワンライナ
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』は、言語に関係なくプロパティベーステストを学びたい人はすぐ買うべき - Magnolia Tech
実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう 作者:Fred HebertラムダノートAmazon Erlang/ElixirのPropErというライブラリをベースに、プロパティベーステストの考え方、テストの実践的な書き方を学ぶための本です。 『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』www.lambdanote.com 書名だけ見ると「Erlang/Elixirは使ってないからなー」と避けてしまうかもしれませんが、それはもったいなく、言語に関係なく、”プロパティベーステスティング”という手法の本質的な活用の仕方が学べるようになっています。 ここしばらくScalaのScalaCheckというプロパティベーステストライブラリを使ってテストを書くことに挑戦していたのですが、今一つより良い書き方が分からず、何か
The AWK Programming Language, Second Edition
Updated Mon Feb 5 10:22:02 EST 2024 Available in paperback and e-book formats. Order at Amazon and other fine booksellers. Introduction This page holds material related to the second edition of The AWK Programming Language. The first edition was written by Al Aho, Brian Kernighan and Peter Weinberger in 1988. Awk has evolved since then, there are multiple implementations, and of course the computi
組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日（月） http://www.jasst.jp/symposium/jasst20niigata.html
開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
プログラミングする時にイケてない関数・変数名をつけないために覚えておきたいネーミングルールの良記事＋ツール8選｜TechClips[テッククリップス]
プログラミングをしていて関数や変数名をつけるときに、毎度のことのように考えるのが手間、とはいえ、適当なネーミングでも違和感あるし……。なにより他のエンジニアが見たときに「なんだこりゃ、分かりにくい。」というのは避けたいところ。 そういったプログラミングにおけるネーミング問題を解消できるツールや情報をまとめてみたので、是非、参考にしてみてください！ 1. codic codic ネーミングと言えば、一度は使ってほしいド定番の「codic」。簡単に言うとネーミング辞典サービスで、日本語の動詞で終わるように文章を入力するとプログラミングでよく使われるようなネーミングを提案してくれます。さらに単語のニュアンスも表示してくれるので、和英辞書のような使い勝手というのが分かりやすいでしょう。さらに、ユーザー登録をすれば、辞書として単語を追加していくといった活用も可能。考えずとも最適なネーミングが生成でき
![プログラミングする時にイケてない関数・変数名をつけないために覚えておきたいネーミングルールの良記事＋ツール8選｜TechClips[テッククリップス]](https://cdn-ak-scissors.b.st-hatena.com/image/square/d4a810ad432ced691ee6614ce4293b93b9e7c1ea/height=288;version=1;width=512/https%3A%2F%2Fobject-storage.tyo1.conoha.io%2Fv1%2Fnc_261159609ad84809af5afcb9e5f56abb%2Ftechclips%2Fimages%2F66%2Fimage.jpeg)
サービスをつくるエンジニアが機械学習を学ぶべき3つの理由 - freee Developers Hub
こんにちは。freee 共同創業者 CTO の横路です。 freeeは現在、「スモールビジネスに携わるすべての人が創造的な活動にフォーカスできるよう」というミッションのもと、テクノロジーによる中小ビジネスのバックオフィス効率化とデータドリブンな経営意思決定支援を実現すべく、スモールビジネスAIラボチームを立ち上げて活動しています。 その中で、サービス・プロダクトづくりをリードし顧客に価値を届けてきたソフトウェアエンジニアこそ機械学習を学び、顧客の課題解決のいちオプションとして身につけはじめるべきだという実感を得たので、エンジニアリング対象としての機械学習について紹介します。 サービスをつくるエンジニアが機械学習を学ぶべき3つの理由 サービス開発で顧客に価値を届けるソフトウェアエンジニアこそが機械学習を学ぶべきだと思う理由は、以下の3つです。 サービスが対象としているトピックについて 深いド
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
積極的にコードの闇を消していこうな - 弥生開発者ブログ
こんにちは。 開発チームのめろたん(@renyamizuno_)です。 マイブームは開発メンバーの写真をトリミングしてSlackの絵文字に追加することです。 これは哀愁ただよう僕の写真です。こくぼさん(@yusuke_kokubo)が「アイキャッチにどうぞ」と作ってくれたのでアイキャッチにしました。 このブログを書いている今ですらこの写真を貼ったことを後悔しています。 ですがせっかく作ってくれたものなので貼ったままにしておきます。 はい。 今回は無駄なコードや深淵をのぞいてしまった時、「あっあっあっ。」と言いながらフタをするのではなく積極的に闇を消していこう。 という話を書きます。 大量のログイン画面 最近実装した画面でログインモーダルを追加することがあり、単純にログインフォームを実装したのですが上手く動きませんでした。 参考にログイン画面を見ようと思ったら、 sessions/new.h
デブサミ2016レポート「今日の習慣が明日をつくる～よりよい技術者を目指して～」 | DevelopersIO
こんにちは、虎塚です。 Developers Summit 2016でセッション【19-C-3】「今日の習慣が明日をつくる～よりよい技術者を目指して～」を聴講したのでレポートします。佐藤太一さんが講演されました。 発表資料 セッション概要 発表者が習慣的に行っているエンジニアとしての訓練のうち、明文化できるもの、価値があると思われるものを整理して伝える。このセッションの目標は、「技術者としての習慣を見直すきっかけを提供すること」。自分にマッチするものを見つけて習慣に取りいれ、皆でよい技術者になろう。 よい技術者とは？ このセッションでは、読む力、書く力、捨てる力の3つが高い技術者を「よい技術者」と定義する。 読む力とは 仕様を読む力 書かれていることを読み取る力だけでなく、仕様に書かれていない暗黙の前提条件や仮定を適切に理解する力を含む より少ない時間でたくさんのコードを把握する能力 関数
Hacker Newsのコメント欄で紹介される数の多い30冊 - YAMDAS現更新履歴
Top 30 Books on Amazon Based on Links in Hacker News Comments 面白いことを調べる人がいるものだ。テック系ニュースサイトとしておなじみ Hacker News におけるコメント欄で紹介される数の多い本を30冊選んでいる。 調べてみたら、だいたい邦訳が出ていた。やはりプログラマのニーズに違いはないということだろうか。邦訳のあるものを紹介数が上のものから並べておく。 アントレプレナーの教科書[新装版] アルゴリズムイントロダクション 第3版 第1巻: 基礎・ソート・データ構造・数学 (世界標準MIT教科書)、アルゴリズムイントロダクション 第3版 第2巻: 高度な設計と解析手法・高度なデータ構造・グラフアルゴリズム (世界標準MIT教科書) 影響力の正体 説得のカラクリを心理学があばく ピープルウエア 第3版 CODE コードから見た
【パズル２】ほとんどのエンジニアには解けるが、下位20％のダメなエンジニアにだけ解けないパズル? - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
前回に続き、Webエンジニア向けのパズルを作った。プログラム言語を問わず、フロントエンド、バックエンド、iOS、Android、どんな技術を担当しているエンジニアであっても誰でも解けるパズルだ。 サイトにアクセスするとHack Me If You Can(ハックできるもんならやってみろ)のタイトルとCall my APIsとあるのみ。分かる人なら数分以内に解けるだろう。 http://challenge-your-limits2.herokuapp.com/ パズルが解けたらコメントを入れられる仕組みにしている。パズルを解いたDarth Vader氏よりイキなコメントが入っている。このDarth Vaderは私の職場の同僚アメリカ人エンジニアのAだ。 Aとは前回のパズルを解いてもらった時は「あーそうか」程度で終わったのだが、今回のパズルに関しては長い議論になった。Aが異を唱えたのはパズルの
FizzBuzz In Too Much Detail
I know. FizzBuzz has been done to death. But I want to use it as a familiar base upon which we can explore some of the common tradeoffs involved in writing and maintaining software. In this article, I’ll show multiple implementations of FizzBuzz, all designed to achieve different goals, and discuss the implications of each. What is FizzBuzz? Hey guys, have you heard about this new FizzBuzz thing?
Bashのよくある間違い | Yakst
原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 本翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます！単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f
Why Rust?
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. While systems programming languages have greatly evolved since the introduction of C more than 40 years ago, our capacity for dumb mistakes with enormous consequences has remained unch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQLとの向き合い方2022年版
組織にテストを書く文化を根付かせる戦略と戦術（2019夏版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2019 Summer Edition
GitHub - codecrafters-io/build-your-own-x: Master programming by recreating your favorite technologies from scratch.
本サイトの全記事をGitHubに置きました！
