TypeScript、上達の瞬間tl;dr 焼肉
積極的な技術選定と消極的な技術選定 - uhyo/blog
この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される（あるいはされない）技術そのものが原因となる意思決定です。 一方、消極
TailwindCSSで学ぶ技術批判の気をつけ方
classNameの設計・分割 classNameの分割・結合にはtailwind-marge + clsxがおすすめ import { merge } from 'tailwind-merge'; import clsx from 'clsx'; const checkboxClass = merge( 'h-4 w-4', clsx({ 'bg-blue-500 border-blue-500': isChecked, 'bg-gray-500 border-gray-500': !isChecked, }) ); <input type="checkbox" className={checkboxClass} checked={isChecked} /> 12 variantsによって切り替えたいものはTailwind Variantsがおすすめ import { tv } from
イマドキの技術同人の大手はどのくらい儲けているのか - くるみ割り書房ブログ
技術書の執筆は儲からない？この業界にいると「技術書の執筆は儲からず、エンジニアにとって割に合わない」という言説をちょくちょく聞きます。試しに Twitter で「技術書 儲からない」と検索してみると驚くほどたくさんのツイートがヒットします。それらを見ていくと、実際に複数の著書を出されているエンジニアの方々のぼやきがあります。 技術書を書いて思ったのは、本当に儲からないということだ。残念ながらもう日本語で書かれた質の良い技術書を手にするのは無理だろう。 — Ryou Ezoe(江添 亮) (@EzoeRyou) December 21, 2020 いわゆる印税や原稿料の金額についてはなんとなく言っちゃいけなさそうな雰囲気を感じてるので公言してないと思うけど、とりあえずIT系技術書や技術雑誌に関しては、書いてる人たちはだいたい「その時間かけて普通にITの仕事した方がはるかにお金になる」レベルだ
技術記事を書く人を大事にしよう
TL;DR 技術記事を書いて公開してくれる人は貴重な資源なので、なるべく潰さないように大事にしましょう。 はじめに プログラムを書いてて、なにかわからないことがあれば検索すると思います。すると、世の中にはごく少数の役に立つ記事と、大多数の役に立たない記事があることがわかるでしょう。その役に立つ記事を求めてネットの海をさまよっていると、「あれ？またこの人の記事だ」と思うことがよくあるでしょう。C++の言語仕様を調べてると「あの人」の、Vim関連を調べていると「あの人」の、Go言語なら「あの人」の記事を見つけることでしょう。逆に言えば、ある程度限定された分野において、体系だった知識があり、わかりやすい記事を書いてくれる人というのは極めて貴重な人材ということになります。 しかし、そんな「つよつよエンジニア」も、はじめから強かったわけではありません。当然のことながら新人時代があり、よくわかっていな
2分間コーディングのすすめ、コードを書く習慣のハードルを下げる
最近私は「2分間コーディング」と呼んでいる取り組みを行っています。文字通り2分間で完了する程度の、非常に簡単なコーディング作業を繰り返すことで、 技術書の最初のページの数行のコードだけ写経して走らせる ネットで見つけたサンプルコードをコピペして走らせる など、多くはコピペするだけで終了するくらいの作業量です。しかし、その頻度を今までの何倍にも増やすのがポイントです。実際にはやっているうちに気分が乗って、そのまま5分、15分以上とコーディングが続くことも多いのですが「まずは2分で終わることだけを始める！」と強く意識することで、コーディングの頻度が大きく増えました。 この記事では、私にとって2分間コーディングがどういう効果があったか、なぜ取り組みを始めたかを紹介します。 効果: 新しい技術を覚えやすくなった 2分間コーディングを始めてから、今まで公式ドキュメントや本を読んだだけで終わってしまい
「DDDで複数集約間の整合性を確保する方法」に対する考察 - かとじゅんの技術日誌
久しぶりにブログ記事を書きますか。 ということで、松岡さん(id:little_hands)のブログ記事に対する考察記事です。 この記事は古くなったので、ぜひ以下も参照してください。 blog.j5ik2o.me little-hands.hatenablog.com 題材も松岡さんのブログ記事と同じもので考えます。 「実装方法1. ユースケースで複数集約を更新する」について考察したいと思います。 注意事項）この記事で使うトランザクションという用語は単なる一連の手続きという意味ではなく、ACID特性を持つRDBのトランザクションという意味です。 class CreateTaskUseCase1( private val taskRepository: TaskRepository, private val taskReportRepository: TaskReportRepository
ふと思いついて書いた。後悔はしていない。 - yamasaのネタ帳
昨日、マルチスレッドなプログラムのコードを読んでたんです。マルチスレッド。 そしたらなんかロックがめちゃくちゃ競合しててパフォーマンスが出ないんです。 で、変更履歴よく見たらなんか全メソッドを一つのmutexでロックして、マルチスレッドに対応した、とか書いてあるんです。 もうね、アホかと。馬鹿かと。 お前らな、単一mutexで囲うだけの対応如きでマルチスレッド対応とか言ってんじゃねーよ、ボケが。 単一mutexだよ、単一mutex。 なんかthreadを作りまくってる箇所もあるし。多重ループの内側でthread生成か。おめでてーな。 よーしデータを細分化してガンガン別スレッドで処理しちゃうぞー、とかやってるの。もう見てらんない。 お前らな、Fork/Joinフレームワークのスレッドプール実装やるからそれ使えと。 マルチスレッドってのはな、もっと殺伐としてるべきなんだよ。 Work-stea
英語の技術文書を早く読むには - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 英語の技術文書を早く読むにはどうしたらいいでしょうか。 注意: この記事の目的は「技術文書について」「早く大意を読み取る」ことを目的としています。 技術文書でないもの，例えば，小説や詩には当てはまりません。 技術文書を読む場合でも，例えば，「論文を批判的に読むとき」や「扱いが悪いと故障する可能性のあるハードウェアのマニュアルを読むとき」には精読すべきですので，この記事は当てはまりません。 頻出英単語を覚える もし「英語の技術文書を早く読みたい！」と悩んでいるとしたら，多くの場合，英語の技術文書を読むのに，英単語をほぼ全て辞書を引いている
リクルートテクノロジーズ エンジニアコース新人研修の内容を公開します！（2020年度版） | Recruit Tech Blog
こんにちは！ リクルートテクノロジーズでセキュリティエンジニアとして活動している、藤原 巧です。 毎年恒例となっており、大きな反響をいただいている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートテクノロジーズでは、新卒採用の新人向けに３ヶ月間の技術研修を行っています。この技術研修では大きく分けて２つのコースが設けられています。 1. プログラミングやWebサービスの構造の基礎を体系的に学び、その後一人につき、ひとつのスマホサイトを企画からリリースまで行うコース 2. 一定以上のプログラミングスキルと開発系経験がある新人に向けた、実際の開発で必要となる様々な技術要素をより深く学び、その後実際のサービスでチーム開発にてOJTを行うコース 今回公開するのは 2. で使用した資料です。 この技術研修は、そのほとんどの部分を内製で実施しています。 この研修の最大の
A Million Hello Worlds - Spinach Forest
テクノロジの流行をファッションに例えて揶揄することがある。新しいテクノロジを追いかけてばかりいるプログラマを非難し、勉強会もいいけど問題解決に頭を使えという。 ファッショナブルなプログラマを責めるのは、衣服や装飾品で散財する人を無駄遣いせず金を貯めろと責めるのに似ている。ユニクロ・無印・（その他無難なブランド）でいいじゃん、それより体でも鍛えなよ、なんて説教するかんじ。一理ある。でも話が通じる気はしない。 おしゃれ貧乏はさておき、人々はなぜ身だしなみに気を使うのだろう。周りと同じがいいなんて消極的な理由もあろう。特定の文化的集団、サブカルチャーに参加するためかもしれない。反対に人と同じが嫌だからかもしれなければ流行りに詳しいところを見せたいからかもしれず、単に目立ちたいからかもしれない。演出したい自己像を求める人もいれば洋服マニアもいる。防寒や衛生や法令遵守だけが衣類への期待とは限らない。
だから、「COBOL」の問題じゃないってば | おごちゃんの雑文
日経コンピュータの馬鹿がまた俺に喧嘩を売る気らしい。 [3]COBOL資産を守って、若者の可能性をつぶす愚 この手の話は既に何度も言ってるので、繰り返しにしかならないのだが、別に「COBOL」が悪いわけじゃない。 それはCOBOLのせいじゃない COBOLは「負の遺産」なんかじゃない 言いたいことはこれらのエントリで言い尽しているのだが、問題は「COBOL」という言語にはない。ある程度歴史を持ってしまった汎用言語は全て同じ危険を持っている。 件のエントリでは「COBOL資産」はあたかも「負債」であるかのようなことを言われているのだが、それ自体は特に負債ではない。そもそも私は、 技術的負債 とかって言葉は嫌いだ。技術者の血と汗の塊を「負債」呼ばわりするなぞ、失礼の極みだ。 件のエントリで問題視するべきなのは、そこじゃない。てか、実のところ件のエントリはそこに触れているのに、力が足りない。 「
新卒ソフトウェアエンジニアのための技術書100冊 - クックパッド開発者ブログ
こんにちは、技術部 高井です。 春といえば、フレッシュマンの季節ですね。このブログを読む方の中には、明日からエンジニアとして新社会人になるという方もいらっしゃるのではないでしょうか。クックパッドでも新しい仲間を迎えるための準備をしていたところで、その準備の一環として「新卒ソフトウェアエンジニアのための技術書100冊」というものを作成しました。 この100冊は、職業ソフトウェアエンジニアとしてキャリアを積むにあたって、読むべき技術書に悩んだら、まずはこのリストから選ぶとよいのではないでしょうかという提案です。 リストに多少の趣味や主張がはいっているのは、まあご愛嬌ということでお許しいただければとおもいますが、職業プログラマとして知っておくべき知識を網羅できるように心がけました。古典と呼ばれる名著についてはできるだけ取りいれ、独習が難しい難解なコンピュータサイエンスの教科書は避けています。これ
Swiftでの文字列比較におけるUnicode正規化を巡る注意点 - Qiita
これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it is certainly consistent with the overall design of the String type to abstract away as many Unicode details as possible. Rule of thumb: if two strings look equal to the user, they will be equal in your code. つまり，「Unicodeでの実装にかかわらず，ユーザ側からの見た目が同じであるからには，コード上でも同一として扱われるべきである」という原則に基づいているとのことです。 実際，この仕様はApple
CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineering
Merry Christmas! GREE Advent Calendar もいよいよ最終日、25日目はグリー株式会社でCTOをしておりますふじもとがお送りします。 今日まで24人のGREE Engineersなみなさまにエントリを書いていただいたわけですが、思ったよりも多種多様な内容で、あらためていろいろな方面で素敵なエンジニアがいるなー、としみじみしてしまいました。いやしかしgitとchefの記事人気ですね、そして、「当然CTOはすごい記事書くんですよね」とプレッシャーをかけて楽しむ仲間たちに囲まれてぼくは幸せです、あーすごい幸せー。そんなプレッシャーの中、今までのエントリとはちょっと方向性を変えて、CTOの話でも書いてみようかと思います。なお、ぼくの趣味は多分問題解決です。 そんなわたくしふじもとは来年で、CTOっていう肩書きでお仕事をはじめて10年とかになるんですが、なかなか先輩と
Post by @shyouhei
ところでPerlリスクですか。まあ、あるんじゃないですか。ぶっちゃけ。でもさあ、さすがにPerlしか書けない人たちは転職先の選択肢のなさくらい自覚してると思う。なのでPerlがどうとかいう話はしないです。各自でどうぞ。 でね、ポイントはそこじゃないだろうと思うわけですよ。どんな選択をしても同様のリスクはあるんですよ。たとえばMacromedia ShockwaveでLingoで作ってたソフトとかさあ。今ではだれもメンテできないでしょう? だから今隆盛をきわめてる技術で作ったものが、何年か後にリスクになるってのは、それはそういうものなんですよ。べつにPerlに限らん。Perlはたまたま今そういうフェーズってだけで、明日は我が身ですよ。hamlとかsassとか。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - OpenInterpreter/open-interpreter: A natural language interface for computers
加賀さんと僕 5 〜艦これウィジェットと個人開発を継続する技術〜