これはpyspa アドベントカレンダー 2024の12日目の記事です。11日目は@aodagの走るということについてでした。 はじめに この15年くらいは、おおむね平均すると毎年2，3人程度の技術者をOn the Job Training（OJT）で教育する機会に恵まれており、その中で蓄積した知見や私の考えを散発的に説明していきます。 私自身は受託開発を主たるビジネスとするシステムインテグレータ（SIer）と呼ばれる企業で働いており、足掛け25年程度のキャリアがありますがソフトウェアについて専門的な教育を受けたことはありません。また、教育についても同様です。 このエントリに記載された内容について何らかのエネルギーを注いでくれる方がいるなら、XあたりのSNSでURL付きで指摘して頂ければ非常にありがたいです。 教育によって形成される技術者像 まずは、どのような技術者なら育てられるのでしょ
このエントリーは pyspa Advent Calendar 2022 の 14 日目の記事である。 昨日は @kuenishi の「我が家の生活物資事情コストコ編」だ。 もはやこのブログがアドベントカレンダー用のサイトになって久しいが、今年もちょっと役に立つ話をしようと思う。 今回の話題は、在宅ワークにかかる環境整備の話だ。コロナが始まったころには盛んに皆さんが自宅の環境を整備するようなエントリを書いていたが、最近は一回りしたのか結構減ってきたように感じている。 単に私の生活環境が完成して、そちらの方面に対する興味関心が薄れただけかもしれないが。 というわけで、このエントリではすでに完成して久しい私の稼働環境について説明する。もう完成してから一年以上は経過しており、細かい変化はあるものの全体としては変わっていない。 少なくとも私が使い込んでいて間違いなく良いと感じているものを説明していく
はじめに#僕がよく知っている業界は SI だが、これに限らずソフトウェア開発の現場には、過酷な現場…いわゆるデスマーチが多いと言われている。 一方で、そのような過酷な現場を渡り歩き生き残ることでしか、良いプログラマになる方法は無いと言った考え方もある。僕の個人的な経験則からすると、この理屈はある程度合っていると思う反面で、合っていて欲しくないという気持ちは強い。 高い技術力をもつプログラマの全てがデスマ職人という訳ではない。 デスマーチに巻き込まれたと気が付いた時の妥当で基本的な戦術は撤退戦だ。何か理由をつけて逃げ出すのが望ましい。つまり、休職なり退職なり、異動なりして、その職場から離れるのが望ましい、出社拒否も良い。しかしながら、何か様々な理由があって、そこから逃げ出せないことはあるだろう。 僕はもう長い事デスマーチに関わることなく生きられているが、徐々に忘れつつあるので、若いころに獲得
このエントリーは pyspa Advent Calendar 2019 の 11 日目の記事です。昨日は @chezou の「Vein の iOS ショートカット複数 URL 対応しました」でした。 はじめに TypeScript は大変に素晴らしい言語で、僕の手によくなじむ。そのせいか最近はめっきり TypeScript ばかり書いている。 今回のエントリでは、僕がこの一年くらいの間に磨いた TypeScript のテンプレートプロジェクトについて説明する。かなり何度も使って必要十分なものだけを含めるようにしている。 しかし、僕の知識の偏りがそのままになっているので、万人に合うというわけではないだろう。 とはいえ、開発環境の初期構築はかなり面倒な作業なので参考にして貰えれば嬉しい。 細かい説明なんかよりもコードを見た方が早いってハードコアな方は、こちらへどうぞ。 taichi/ts-t
はじめに#最近、様々な分野でチャットツールのビジネス利用が試行されていますね。 筆者の会社でも例に漏れず多くの部門が Slack を利用したり、Microsoft Teams の検証をしています。 筆者は 20 年近く様々なチャットツールを使ってきました。1:1 のチャットツールだけでなく、複数人で使うチャットツールも様々な状況で利用しています。 そもそもインターネットを利用する筆者の主たる目的の一つは確実にチャットです。 一方で、会社に本格的なチャットツールを導入する過程で分かってきたのは、多くの人は思ったよりチャットツールに慣れてない、ということです。 このエントリでは、最近 Slack や Teams のようなチャットツールを使い始めた組織に所属するみなさんに向けて、チャットツールをより快適に使うための考え方や Tips を紹介します。 ここで紹介する知識は、筆者からの提案であり何ら
このエントリーは pyspa Advent Calendar 2017 の 12 日目の記事です。昨日は @mururururu のエントリでした。 はじめに#僕はまごうこと無き運動不足である。週に一回は肩こりの症状を緩和するためにクライミングジムに通ってはいるが、それほど真剣にやっている訳ではないので、三級程度で二年くらい足踏みしている。 しかし、最近は体力の衰えを明確に感じるようになってきた。それは、集中力の低下や、好奇心の低下となって確実に表れている。以前なら、体力任せにコードを書き続けられたが、今はもう全くそんな事ができる気配もない。 と言う訳で、今日は僕が筋トレを始めたという話をする。 去年は筋肉を溶かす話をしたが、今年は筋肉を作る話をするってわけだ。 筋トレを始めた理由#まずは、筋トレを始めた理由から説明していこう。と言っても、実にありふれた話だ。 人間ドックで警告を受けた#一
このエントリーは pyspa Advent Calendar 2016 の 13 日目の記事です。昨日は @ymotongpoo のエントリでした。 @ymotongpoo は筋肉を作る話をしていたが、ここでは筋肉を溶かす話をする。半年の訓練が一週間で全部無に還るような類の話だ。 はじめに#現代人は突き詰めると塩と油に脳をやられている。 現代人が短絡的に喜ぶ食事を考えた時、塩と油の不快感を感じさせずに大量摂取させることが出来る料理が幸福感をおおむね最大化する（要出典）。 塩と油を効率よく摂取させるにあたって、様々な料理が考えられるが、今日は家庭で簡単に作れる邪悪な食事について紹介したい。 僕が考える最大限に邪悪で、作成者の手間が少ない調理とはポテトサラダ（ポテサラ）である。 世間では男の胃袋を握る手段として「肉じゃが」が推奨されるが、同じイモ料理として僕は「ポテサラ」を推したい。 何の気な
まずは、会場に来て下さった皆様、本当にありがとうございました。 ご来場の皆様が何か少しでも得るものがあったのであればいいなぁ…と考えます。 面白いイベントを企画して僕を呼んでくれた jxck には感謝しかありません。 このエントリでは、話足りなくてモヤモヤした部分を勢いで書きなぐってる感じなので、無駄に長い割にオチが無いので暇な人だけが読んで下さい。 観客として参加したセッションについて#僕が見ていたセッションは、 server_perfstandardizationhttp2monitoringです。僕の主観としては余り未来の話をしてなくて現状確認に終始した後に、最後の 15 分くらい未来をチラ見せみたいな感じだったかなぁ…と感じています。 しかしもって、未来みたいなものの話をするのは兎に角難しいので、少しでも未来っぽい話出来ればそれで良いんじゃないかと考えます。 セッションについて#僕
このたび JSON パーザのベンチマークを書きましたので、どうぞご査収下さい。 taichi/json-benchmarks Java8 がインストール済みの環境で、当該リポジトリを clone して と実行する事で追試できます。 結果について#jackson-databind が最速なので殆どの皆様におかれましては安心して下さい。 特に驚きに値するような事は何も起きていません。 僕のマシンで実行した結果はこちらです。（エビデンスが無いとの指摘を受け追記しました。） Json benchmark results結構な長文になってしまいましたので、マニアな皆様だけが続きを読んで下さい。 課題設定について#まず、おおまかな課題設定について説明します。 JMH を使った本格的なベンチマークを書くJava 用 JSON パーザのショーケースを作る事で使い易いものを明らかにする結局どのパーザが速いの
僕は Java 方面に慣れていますのでslf4j(Logback)やlog4j2の様なロギングライブラリがあると扱い易いなぁ…と思う次第です。 まとめ#例によって結論から書くと XML で設定する事に耐えられる ならseelogがオススメ。 CLI で指定出来る程度の設定が出来れば良いなら、公式リリースなglogがオススメ。 標準のlogパッケージについて#まず、僕の開発環境は Windows7 ですので、log/syslog を直接使うようなコードは避けたいのです。 加えて、コードをあまり変更せずに出力先や出力内容を変更したいのですけども、その為の標準的な方法は機能としてライブラリ内に組込まれていません。 テスティングフレームワークの時も同様に感じましたけども、go 言語のコアライブラリは本当に一番下の足回りがあるのみです。 例えば、設定可能な項目はこれだけです。抜粋すると、 時間や日付
JJUG CCC 2015 Spring（4 月 11 日開催） で発表をしてきました。 一コマ目であり、エントランスから一番近い入り易い場所だったせいもあるとは思いますが立ち見が出る程の盛況ぶりでした。発表を聞いて下さった皆様、本当にありがとうございます。 発表資料はこちらです。 Past & Future of null in Java発表者がどういう風に考えてコンテンツを作り、どういう準備をしているのか、というのは余り共有されていないように思います このエントリでは僕がどの様に事前準備を行い、当日はどんな風に考えながら発表していたのか記録しておきます。 事前準備#内容の決め方#まず、50 分では前提条件の多くなる話はできませんので、凡そ言語仕様かライブラリの話をするのが妥当でしょうとアタリを付けます。 恐らくビギナー向けを標榜しつつも、設計方法論などメタモデルについて話をするのが良い
このエントリは、アイディアや情報の提供を呼びかけるためのものです。 結局何がしたいのか#自前の AnnotationProcessor で Meta-Annotation 的な機能をサポートしたい。 で、そもそも Meta-Annotation ってこんなんで良いんだっけ？というエントリです。 解決したい問題#同じアノテーションの組合せを沢山のクラスに設定したくない#アノテーションの合成#こういう二つのアノテーションがあったとして
Python で実装され、その後 Java にも移植されたソートアルゴリズムである TimSort が盛大にバグっていることが発見されました。 このバグがどのようにして発生するのかについては、以下のドキュメントを精査して下さい。 TimSort fails with ArrayIndexOutOfBoundsException on worst case long arraysOpenJDK’s java.utils.Collection.sort() is broken: The good, the bad and the worst caseどんなことが起こるのか#通常の利用では想定しえない場所でArrayIndexOutOfBoundsExceptionが発生します。 例えば、以下のようなスタックトレースになります。 Exception in thread "main" java.l
WEB+DB PRESS の Vol.85 で、E2E テストの記事を書いたので是非読んでくださし。 2015/2/24 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.85@Gihyo Digital Publishing今回の記事における対象読者について#Selenium は知ってるけど WebDriver の API 辛すぎﾜﾛﾀという方を対象に記事を書きました。僕もそうです。 WebDriver の API は本当に本当に使い辛いのですが Geb なら、それが大きく低減されますので是非一度さわってみて欲しいですね。 jQuery に似てるけど所々違う様な感じがする API 越しに DOM を検証するのは便利ですよ。それによって大切な何かを失ってる感は確かにあります。
WEB+DB PRESS の Vol.83 で、負荷テストの記事を書いたので是非読んで頂きたい。 2014/10/24 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.83@Gihyo Digital Publishing今回の記事における対象読者について#JMeter だ、JMeter を撃滅せよ。 負荷テストスクリプト書くのに GUI なんぞいらないのですよ。 素人騙すんなら、それでいいかも知らんけども、そういう事じゃないでしょう。 GUI なしでも書けますよって、そのヤヴァイ XML を俺に見せるな。 負荷かけてる最中にサーバより先に死んだりするような負荷テストツールを後生大事に使うのをやめて欲しいのです。 今回は、新進気鋭のツールであるところのGatlingを紹介し
WEB+DB PRESS の Vol.81 から JVM を中心とした連載を始めましたので是非買って下さい。 2014/6/24 発売です。書店には既に並んでいるかと思います。 これはアマゾンのアフィリエイトリンクですので、踏んだ直後に冷蔵庫等の大型家電を購入して頂けると僕が喜びます。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.81@Gihyo Digital Publishing 初回の内容はラムダ式 + RxJava 今回の内容としては Java8 のラムダ式に関する簡単な説明から、ラムダ式を利用してRxJavaを使うとこんなに便利という話を書きました。 記事内で Stream API に関して説明しなかった最大の理由はラムダ式と Stream API に関する適切で妥当な説明については桜庭さんの記事を読めば良い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
