最近調べた qwik というライブラリが結構面白かったので、実際どういうものなのかとか紹介してみます。 qwik とは qwik は Web 向けの View ライブラリです (React や Vue.js の仲間)。パフォーマンスオタクがパフォーマンスの最適化 (Web Vitals の改善) にこだわって作ったライブラリです *1。 すでにいくつも良い紹介資料があるので、まずはこれらをいくつか読んでみると良いと思います。 Resumable な JavaScript フレームワーク Qwik を学ぶ Qwikの基本概念である Resumable を理解する Qwikというフレームワークについて - console.lealog(); Qwik調べてみたら結構面白かった qwik の詳しい使い方などは先人の記事に譲ることにして、以降は id:mizdra が個人的に面白いと思ったことを書
●発表のアーカイブ動画はこちら:https://youtu.be/4rgGkoyUaZw ●発表の中で紹介しているUdemy講座:https://www.nextskill.co.jp/courses === プログラミングの基礎を学び、アプリケーション開発に実践的に関わり始めると、「MVC」「サービスクラス」「ドメインモデル」「クリーンアーキテクチャ」といった、よく分からない単語に遭遇します。 これはいわゆる「アプリケーションアーキテクチャ」という分野の話で、アプリケーション開発に関わり始めると、誰もが突き当たる壁の一つです。 今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの、基本的な用語の意味や関係性を整理します。 発表者が過去に書いた以下の記事を中心に、+α の内容を加えた発表になります。 ・「ビジネスロジック」とは何か、どう実装
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か?」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。 社内勉強会を始めたけれど長く続かないという話は時々、知人から聞いたり Twitter で見かけたりすることがあります。 今回は NTT Com で 2014 年から 8 年間続いている社内勉強会 TechLunch の運営を続ける際に行っていることについて書きたいと思います。 本記事は少々長めになっているため、先に内容をまとめると以下のようになります。 社内勉強会 TechLunch の紹介 社内勉強会を長く続けるためにどんなことを考えたか 続けていくために「ゆるく」したこと 発表の敷居を下げる 運営が頑張りすぎない 参加者にもゆるく楽しんでもらう TechLunch とは NTTコミュニケーションズでは、TechLunch と称して社内ラ
『ソフトウェアアーキテクチャ・ハードパーツ』を訳者の方からご恵贈いただきました。ありがとうございます。献本については基本的にすべて書評を書こうと思っているため、今回も記事にします。発売は10/27のようです。 ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazon おことわり まず指示語についてです。記事中で「本書」「この本」と書く場合は『ソフトウェアアーキテクチャ・ハードパーツ』を指します。また、「著者」は本書を執筆した人を指すものとします。「筆者」といった場合、それは私のことです。 いわゆるスキミングをした状態で一旦書評をするため、本書の細かい議論の見落としや用語の誤認識が含まれる可能性があります。この書評は
このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験(学習)できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項(いいわけ) 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか?については
anond:20211014160920 自治体が人を雇う場合、一般的な雇用契約をすることができない。少し前までは曖昧にされてたが、総務省が古い解釈を今更示したせいで、一時的であれ短時間であれ、明確に公務員として任用せねばならなくなった。令和2年度4月から施行された会計年度任用職員てやつだ。地方公務員法の根拠規定によりパートタイム(第22条の2第1項第1号)とフルタイム(〃第2号)の二種類があるが今回はパートタイムのほう。本来は。その場合は地方自治法第203条の2第1項により「報酬」の支給となり、勤務条件に関して県の条例の適用も、労働者として労働基準法の適用もある。任用条件の通知も当然行われる(「会計年度任用職員の任用(再度の任用を含む)時に交付する「勤務条件通知書のイメージ」の作成等について - 全国町村会」)。 埼玉県の条例 会計年度任用職員の報酬等に関する条例 会計年度任用職員の報酬
現在埼玉県のワクチン接種センターで看護師として働いている。 今までで一番クソなワクチンバイトだったので、長くてごめんだけど誰かに聞いてほしい。 (長くなりすぎたので追記は一番下にまとめた) まずざっくり言うと、はじめに聞いていた内容と違う仕事をやらされたり突然出勤調整をされたりしたが、そもそも看護師は県の認識では【労働者ではない】とのこと。要するに何かを訴える権利すらないと伝えられたのである。 7月に募集がかかり、勤務期間は8月頭から11月末だった。 県の看護協会を通じて募集があり、その後は埼玉県と直接のやりとりをしていた。 条件についてはメールで下記が記載されていた。 ・従事場所 ・期間(供給状況で前後する場合あり・施設メンテナンスのため休みになる場合あり) ・業務内容 ・従事時間 ・時給(交通費込み・謝金のため社会保険がないこと) なのでてっきり県との直接雇用的な感じだと思っていた。
2010年代初頭にブラジルの新世代が発見され、「ミナス新世代」として日本に紹介された。そのきっかけはマルチ奏者のアントニオ・ロウレイロ。彼の音楽の新鮮さはすぐにリスナーの間に広がり、彼と共演しているブラジルの同世代の豊かな才能たちが芋づる式に発見されていった。彼らの何人かは来日も果たしたし、アレシャンドリ・アンドレスやハファエル・マルチニらに関しては日本盤のリリースもあった。2010年代半ばには現代ジャズの最重要人物の一人でもあるギタリストのカート・ローゼンウィンケルが自作『Caipi』にアントニオ・ロウレイロ(とペドロ・マルチンス)を起用したこともあり、ジャズ・リスナーにとっても広く知られるようになった。 そんなアントニオ・ロウレイロらのコミュニティの中でも鍵盤奏者で作編曲家のハファエル・マルチニは中心人物のひとりと言っていい存在だった。グルーポ・ハモ『Ramo e a Liberdad
こんにちは。ユーザープラットフォーム開発本部(UP部)の原です。 あなたのチームの雑談チャンネルは1日あたり何回ぐらい発言がありますか? 小さい仲良しチームなら頻繁に発言があるかもしれませんが20人,30人あたりになってくるとだんだん発言が少なくなってきますよね。 チームメンバーのエンゲージメントや生産性を高めるためには少なくともお互いがどんな人なのかを知っているようにしておくべきです。 JMDCは数百人いる組織だし、私の所属するUP部だけでも20名以上の社員が所属しており、しかもほぼ全員リモートで仕事をしている状況なので、いかに "チームメンバーがお互いにどんな人なのかを知っている状態" を作り出すかが課題になっています。 GitLabのリモートワークガイド参考にする 自らを “A world leader in remote work” と呼んでいるGitLabも雑談を重要なものと捉え
11月にリメイク版が発売されるので思い出話を書いてみたい。 今から25年前の1997年ののこと。当時小学生だった自分の1歳年上の従兄が、夏休みにお婆ちゃんの家にこのゲームを持ってきていたのが全ての始まりだった。 「タクティクスオウガっていうゲームがあるんだ。すげーから一緒にやろうぜ。」 従兄に勧められるままゲームを始めたのだが、タクティクスオウガが『すげー』ことはすぐに分かった。 中世ヨーロッパ風の権謀術数渦巻く世界観。重厚なBGMの中で敵味方がターン関係なく立体的なマップで繰り広げるリアルな戦闘。 背中に翼の生えたキャラクターが民家の屋根の上に移動して弓を射ると放物線上に矢が飛んでいくわ、ふわふわと宙に浮かぶ幽霊が魔法を唱え敵が炎に包まれると足元の草が焼けるわと細部までこだわったビジュアル。 とにかく衝撃的なゲームだった。いてもたってもいられなくなり、従兄がお婆ちゃんの家から帰った直後に
政治構造への従来の認識と、最近の統一教会関連の報道を合わせると、だいたいこんな感じだろうかと現時点で思うところのメモ。 ゲームのルール 国政は数のゲーム。多数決による。 多数決は「採決の前に議論が尽くされ(修正が施され)、十分な情報が採決者にインプットされていること」が前提・理念で、本来はただの「数のゲーム」ではないが、多数派が理念を無視することで無化される。 無化する理屈として「多数決で選ばれた=全員が賛成」というすり替えが多い(与党だから国民の意思そのもの、というような) 多数決で勝つための数(議員数)を増やせる人物/集団(政治家/派閥)が力を持つ。 議員の数を増やすには、選挙で票を集める必要がある。 選挙の票には組織票と浮動票が(仮に分類すると)ある。 世間の感心が低く投票率が低い時、組織票の相対的な割合が高まる。 組織票の「当落の正確なカウントができる」「組織票の倍が彼我の差になる
howto-tech-docs.md 技術文書の書き方 このメモは、私(@ymmt2005)が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く