自分が関わったSI案件のコードメンテナンスとその価値
僕がSI案件に関わりはじめてから早5年目に突入しました。SI案件に関わるようになった経緯については、2021-2022年のお仕事近況報告に詳しく書きましたが、あれからも継続してプロジェクトに関わり続けています。 それなりに長くプロジェクトに関わってきたので、保守や改修という業務も発生してきたわけですが、今日は僕が主導するプロジェクトでどのようにコードのメンテナンスを行いながら長期的にプロジェクトをやっているかを書いておきたいと思います。 コードメンテンナンスの機会が作りにくいSI案件 # もちろんプロジェクトによって様々な状況があるので一概には言えませんが、僕が関わっているSI案件のプロダクトだと、コードメンテナンスを実施する機会がほとんどないと感じました（正確にはリリースするタイミングがない）。 その理由は、リリース後に不具合が多発したプロジェクトの場合はその対応に追われ、逆に不具合がほ
原器としてのHHKB
HHKBはプログラマーに愛されるキーボードであると同時に、万能な単位としても有名です。具体的な説明としては、kyoh86さんの次の説明がわかりやすいです。 エイチ エイチ ケイ ビー【HHKB】〔←Happy Hacking Keyboard〕 ① 株式会社PFUが提供する高性能コンパクトキーボード。 比較的廉価でありながら、シンプルかつコンパクトで性能の良いキーボードとして人気がある。 その正式名称からハッピーハッキングキーボード、とも。 ② 長さ、重さ、面積、体積、金額の単位。 「このオーブンの内寸は底面が2───程度だ」 「今月は120───程度しか:spin_keizai:してない」 ─── たんいけい【───単位系】 現在国際的に使用されているガジェット評価の単位系であり、 長さ、重さ、面積、体積、金額の5つをHHKB基準とした物理量として構成し、 またそれの乗法、除法で導かれる
インプレスの「いちばんやさしいWeb3の教本」回収判断について
インプレスは回収して内容修正するべきと書いた書籍「いちばんやさしいWeb3の教本」ですが、その4日後となる2022年7月25日に出版元であるインプレスより、本書の回収についての発表がありました。 弊社2022年7月20日発行の書籍『いちばんやさしいWeb3の教本 人気講師が教えるNFT、DAO、DeFiが織りなす新世界』の内容に関しまして、SNSを中心に読者の皆様よりさまざまなご意見をいただき、著者ならびに外部有識者、編集部において内容の検証、精査を行ってまいりました（※）が、ご意見いただいた誤りやわかりづらい表現箇所を修正・反映しての本書の販売継続は難しいと判断し、本書の販売を終了させていただくことといたしました。つきましては、本書の回収を実施いたしますとともに、第1章・第2章の無料公開を中止とさせていただきます。改訂版の発売につきましては決定しておりません。 ※検証方法について 202
書籍「いちばんやさしいWeb3の教本」は本当に酷い内容だし、Web3界隈の人は一致団結して間違いを指摘して、インプレスは回収して内容修正するべき
2022年7月26日追記：インプレスの「いちばんやさしいWeb3の教本」回収判断についてという記事を書きましたので、こちらもあわせてご覧ください。 著者の方には申し訳ないのですが、下記のツイートで存在を知った「いちばんやさしいweb3の教本」という書籍が本当に酷い内容です（内容が気になる人は、2022年7月31日までインプレスのサイトで1、2章が無料公開されていますので、ぜひご覧ください） 。 Web3の説明ではだいたいGAFAがディスられるけど、「TCP/IP、SMTP、HTTPはGoogleやAmazonに独占されてる」というのはさすがに理不尽すぎる pic.twitter.com/amgEU3Gmpg — catnose (@catnose99) July 19, 2022 #いちやさWeb3 実在する技術用語をやさしく噛み砕いているようで実際のところ意味不明なワードサラダなので悪質
lsp-modeのLSPサーバーをプロジェクト別に切り替える方法
最近、Denoの開発をはじめたことにより、EmacsでTypeScriptの開発をするときに、lsp-modeで起動するLSPサーバーをプロジェクトによってNode.js（ts-ls）とDeno（deno-ls）で切り替えたいと思いました。 lsp-modeはすでにJavascript/Typescript (deno)をサポートしているので、おそらくできるはです。 公式回答はディレクトリローカル変数を使う # 調べてみたところ、公式ドキュメントのFAQに次の記載がありました。 I have multiple language servers for language FOO and I want to select the server per project, what can I do? You may create dir-local for each of the project
Emacsの次世代ミニバッファ補完UI | 日々、とんは語る。
先日、ネイティブコンパイルEmacsが登場でElispをネイティブコードにコンパイルすることによりEmacsの高速化が実現されたという記事を書きましたが、Emacsに到来している新しい波はこれだけではありません。Emacsを華麗に操作するユーザーインターフェイス（以下、UI）にも新潮流がきています。 百聞は一見にしかずというわけで、まずはこちらの動画をご覧ください。 この動画ではEmacsの起動時点から次の操作を行なってファイルを開いています。 ghqでリポジトリ検索 → fdでファイル検索 ghqでリポジトリ検索 → ripgrepでテキスト検索 利用している外部コマンドはさておき、標準のEmacsと大きく違うところは、コマンドを実行するとミニバッファが縦に伸びて補完候補が表示され、キー入力による候補の絞り込みをしてファイルを開いているところになります。 Anything/Helmと違っ
エンジニアの楽園 vim-jp
インターネットが大好きな人の多くは、どこかしらのコミュニティを拠点として活動を続けることが多いです。 僕は2003年からのネットユーザーなのでそこまで古くはないのですが、かつて、はてなダイアリー、IRCなどを拠点として、ネットで活動してきました。現在であれば、Twitter、Qiita、Zennなどを主軸として活動している人が多い印象です。 そんな中、最近僕が最も居心地よく滞在しているコミュニティがvim-jpのSlackです。 なぜvim-jpなのか # 僕を知っている人であれば、「お前はEmacsユーザーだろう？まさかVimに乗りかえたのか？」というツッコミたくなるかもしれませんが、それにはおよびません。なぜなら、いまもEmacsユーザーであることに違いないからです。 では、なぜvim-jpに入っているのか？それは次の理由があるからです。 幅広い分野の話題が可能 # vim-jpは、い
ネイティブコンパイルEmacsの登場
日本時間の2021年4月26日午前3時6分、Emacsのmasterブランチにfeature/native-compブランチがマージされました（コミット：Merge branch ‘feature/native-comp’ into into trunk）。これにより、HEADのEmacsをビルドすると、Native compilation機能を兼ね備えたネイティブコンパイルEmacs、通称Gcc Emacsが使えるようになりました。 ネイティブコンパイルEmacsの機能 # ネイティブコンパイルEmacs（以下、Gcc Emacsと呼びます）は、Andrea Corallo、Luca Nassi、Nicola Mancaの3名によるBringing GNU Emacs to Native Code という論文で詳細が説明されています。 簡単に説明すると、これまでのEmacsは、Elisp
風になりたい奴だけがEmacsを使えばいい 2020
先日、Emacsに一生入門できねえ2020という記事を目にした。 確かにEmacsは難しい。まったくもって増田の言う通りだ。うんうんと頷きながら、過去に自分が書いた「風になりたい奴だけが Emacs を使えばいい。」という記事が脳裏に浮かんだ。 10年間の出来事 # 僕が「風になりたい奴だけがEmacsを使えばいい」と言った記事は2010年9月4日に投稿されていて、あれから実に10年の月日が経過していた。とても懐しい。 振り返ればこの10年間でエディタの世界は大きく変わった。次世代エディタを銘打ったAtomが誕生し、エディタにおける表現の限界をぶち壊した。そして後続で登場したVSCodeが一気にシェアを奪い、一瞬でトップシェアの座に立ってしまった。予想しなかった未来があった。 一方、Emacsはどうなったかと言えば、メジャーバージョンが23から27になった。しかし、起動したてのEmacsは
Emacsで自動修正を実現する auto-fix.el
AtomからEmacsに引越しする中で、AtomにあってEmacsにはなく、これがないと快適なプログラミングは厳しいというパッケージや機能が幾つかありました。 その中のひとつが、コードの自動修正機能を提供するパッケージです。 エディタでコードを自動修正する # 個人的な感覚ではGo言語とgofmtの登場以降、いわゆるインデントのタブ・スペース論争やコーディングスタイルについては、プロジェクト毎に利用するコードフォーマッタに任せるという流れで決着がついたと思っています。 最近良く書くJavaScriptやTypeScriptでは、ESLint、TSLint、Prettierが主流になったお陰もあり、僕みたいな様々な会社のプロジェクトで開発を行う人間も、インデント、クォート、文末のセミコロンなどの修正はプログラムに任せて、僕は適当に書いて保存するだけで自然に統一がはかられるようになりました。
AtomからEmacsに乗り換えて気付いたEmacsの底力
2018年の年末にAtomからEmacsにスイッチしてしようと決めてから、年末年始を利用して快適にコードが編集できるようにEmacsを鍛えていました。 Atomは大変素晴しいコードエディタで、初心者がプログラムを書く上で、必要な機能が最初から備わっています。これはVSCodeも同様でしょう。まさに生まれながらのプログラミングエディタと言えます。 Emacsに復帰してあらためて思ったのは、Emacsは生まれながらのプログラミングエディタではないということです。Emacsの初期設定でプログラミングをするには、自動補完もなければGitの対応も不十分で、あまりにも機能が足りていません。 ですが、Emacsが他のエディタと比べて劣っているかと言えばそうではありません。 Emacsの最大利点は即時拡張性 # 僕が感じたEmacsがAtomやVSCodeと比べて優れている点は「即時拡張性」です。 Ema
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
