2024-10-05 YAPC::Hakodate 2024 https://yapcjapan.org/2024hakodate/
この1~2年ほど、国のさまざまなレベルで英語教育政策の根幹にかかわるような大きな動きがありました。2011年7月に「国際共通語としての英語力向上のための5つの提言と具体的施策」がとりまとめられ、その提言の1つ目が「生徒に求められる英語力について、その達成状況を把握・検証する」というものでした。ここから国としての学習到達目標をCAN-DOリストの形で設定すること、という提案が明示されて、欧州言語共通参照枠(CEFR)の考え方がクローズアップされ、高校・中学でのCAN-DOリスト作成の流れが生まれてきます。 昨年春には「大学入試にTOEFLを」という国会議員の提言に端を発して、大学入試に代わる4技能テスト導入の可能性が議論され、秋には教育再生実行会議第4次提言で「達成度テスト」という表現で一発勝負の大学受験に代わるシステムの提案がされ、テスト開発会社は4技能テストの構築にしのぎを削っています。
「守破離」の本当の意味知ってる?有名な「守破離」という学習モデルがある。これについて、色々疑問をもって以前調べたことがある。 根本的な問いとして、最初から「守」として型を受け入れるところがスタートでは、本当にその「守」が必要な理由、型が生まれた動機が掴めないのではないか?という疑問があったからだ。 「守破離」については、多くの人が勝手な解釈をしているので、冒頭のscrapbox(cosense)のリンクでは、守破離の起源や本当の意味を調査したのでぜひ見ておいてほしい。(ちなみに調査は『甲陽軍鑑』を入手するところまで行ったが、入手した部分の『甲陽軍鑑』の中で守破離に言及する部分を見つけることができずに途中で断念した。国会図書館などで調べることができる方はぜひ教えていただきたい。) 「守破離」から、「破守破離」そして「我守破離」へ経験則として、個人的に意識してやってきているのは、なんでも「これ
先日NewRelicの清水さんにマンツーマンでオブザーバビリティの話をきかせてもらえるという貴重な経験をした。長年アプリケーションレイヤーも含んでシステム運用の経験があると「あるある」な話なのだが、次のようなことが起こる。 何か不具合や障害が起こる 該当時刻のエラーログなどを見るが情報が少なく、原因を特定する決定打に欠ける 次回、また同じことが起こったときには原因を特定できるように、printfデバッグするコードを大量に埋め込んだバージョンに更新して、デプロイする もう一度起こるのを待つ これは最初の状態が「オブザーバビリティに欠けた状態」だったと言える。めちゃ納得してEnter Sandmanくらいヘドバンして頷いてしまう。 僕の経験上このようなケースを避けるために良い結果を出してきたのは、Javaの例外が出た箇所でスタックトレースを取得しておくことだ(僕らは単にログファイルに吐いておい
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル:2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi
ソフトウェアエンジニアリングの第一人者である和田卓人氏が、自動テストの本質と望ましい姿について語りました。コスト削減ではなく「変化に対応する力」を得るための自動テストの重要性や、信頼性の高い自動テストを実現するための具体的な方法論を解説。まずは、偽陽性や偽陰性の罠を避け、持続可能なソフトウェア開発を実現するための洞察に満ちた講演内容を紹介しました。全4回。 和田卓人氏自己紹介 和田卓人氏:よろしくお願いします。 (会場拍手) お招きいただきましてありがとうございます。「望ましい自動テストとは」というタイトルで、自動テストに関するお話をさせていただきたいと思います。和田卓人と申します。インターネット上ではだいたい「t-wada」さんと呼ばれていて、t-wadaアカウントが下にいろいろ並んでいるんですが、ソーシャルアカウントをいろいろやっていますという感じです。 本日の講演、私の講演はいつもス
第1章 序論……1 1.1 はじめに……1 1.2 先行研究……1 1.3 本研究の目的……2 1.4 フルートの構造および材質について……3 第2 章 シェッフェの一対比較法を用いた主観評価実験……4 2.1 使用楽器……4 2.2 評価手法の決定……6 2.3 評価内容の決定……6 2.4 演奏内容……7 2.5 実験参加者……8 2.6 実験装置……9 2.7 提示順表の作成……10 2.8 実験方法……12 第3 章 主観評価実験-分析方法……23 3.1 データ整理……23 3.2 母数の推定……24 3.3 一元配置分散分析……24 第4 章 主観評価実験-結果と考察……26 4.1 結果……26 4.1.1 実験1(吹奏感)……26 4.1.2 実験2(音色)……34 4.1.3 アンケート……41 4.2 考察……42続きを見る
かねてより人間、とりわけ労働者や従業員をリソースと呼ぶことについて批判的な意見を聞くことがあった。 2018 Don't call people resources - Ben Linders 2021 社員を「リソース」と呼んではいけない――。 | d's JOURNAL(dsj)- 理想の人事へ、ショートカット 2022 人間をリソースと呼ばない方がいいと思う - ジムには乗りたい 加えて、これらの主張に対するカウンターを見たこともある。「問題の所在が不明瞭」「情緒的な意見のみで代替が示されない」「人材を人財と書くような言葉遊びでは」等々。俗っぽく言えばここにあるのは、「モノ扱いしないでほしい」vs「とは言っても経営管理上はヒト・モノ・カネ・情報はリソースでしょ」という対立である。 この件について「人間をリソースと呼ぶことの問題についてアカデミックな見解・理論はあるのか」「人間をリソー
普段RunbookはApple SiliconのMacで開発しており、運用環境も極力Armベースで統一することにしました。これまではx86系のインスタンスを使用していたので、若干不安もありましたが、検証してみると特に問題はないことがわかり、コストメリットもかなり受けられることがわかりました。 ただArmベースのインスタンスについてググってみると、こちらの記事のように、エントロピーが少ないせいでパフォーマンスが低下するので注意しようという情報がいくつもヒットします。 EC2 の Arm では、random デバイスに対するエントロピーがとても少ない場合によってはエラー、もしくは大幅なパフォーマンス低下を引き起こします。 今回は Apache Tomcat(java) を利用して乱数生成する部分のパフォーマンスが、大幅に低下しました。 これは乱数生成で /dev/random を利用するのです
Snowflakeのマイクロパーティション Snowflakeのデータウェアハウスとしてのスケーラビリティ、パフォーマンス、多くの有用な機能の根源の一つに、マイクロパーティションというアーキテクチャの良さがあります。 Snowflakeはオブジェクトストレージ上に構成されたマイクロパーティションと、そのメタデータを徹底的に最適化することで、ACID制御からタイムトラベルまで、多くの機能をとてもうまく実装しています。(でもこのアーキって最近よく聞くIcebergや他のオープンテーブルフォーマットとちょっと似てない?というのは今回とは別のお話) マイクロパーティションを超わかりやすく解説されているほーりーさんの素晴らしい記事はこちら。 このマイクロパーティションはプルーニングという仕組みにより、Snowflakeのパフォーマンス向上に絶大な影響を与えています。解説記事はこちら。 最近、マイクロ
When Miggo onboards customers, we gain visibility into application behaviors from within. This unique perch allows Miggo Research to discover and address new vulnerabilities impacting thousands of organizations. That’s exactly what happened with ALBeast. This blog details the technical aspects of that discovery, including Miggo’s recommendations for mitigation. For a broader overview, we invite yo
最近は、ITが面白いだとかつまらんだとか言って盛り上がってるけども、面白いってのは、どういうことか、ちょっと考えてみようか。 知識と学習#一つ目は、学習するに足るだけの知識体系がそこにあるかどうか。 知らない事を知る、出来なかったことが出来るようになる快感ってのは、何度経験しても最高なんであって、一人でも多くの人にこの体験をして欲しい。素晴らしいことに、ソフトウェア技術だけに範囲を絞ってもまだ理解できてない事は大量にあるし、増え続けてる。 生成AIがアシスタントしてくれるけど、ちょいちょい嘘をついてくるってのが、また熱いよね。AIが言ってる事だけを真に受けちゃダメで自分でちゃんと試さないといけない。そして、インターネット上に無い情報について、やつらは手も足もでない。 最近は新しい技術が出てこないなんて言ってる連中もいるようだが、現実の社会課題を解決し、それを付加価値として提供できて初めて新
TL;DR: uv is an extremely fast Python package manager, written in Rust. We first released uv in February as a drop-in replacement for common pip workflows. Today, we're announcing a series of features that extend uv beyond a pip alternative, and into an end-to-end solution for managing Python projects, command-line tools, single-file scripts, and even Python itself. It's Cargo, for Python: a unifi
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
総集編の映画の公開に合わせて、というか、アニメが放送/配信されてからずっと、25年以上続いているアジカンの古い楽曲や歴史を追ってもらえて率直に嬉しい。結成から一度も止まらずにバンドは転がり続けているけれど、ポップミュージックはユースカルチャーとしての側面もあるから、当時の中高生や同世代と共に俺たちも年を重ねて、アジの缶詰なのか密教の瞑想法なのか、誤解や興味の端っこはおろか若い世代に発見されなくなっていくのも仕方がないことだと思う。 しかしながら、前述したように、バンドも俺たちの人生もアラフィフなりに全力で転がり続けていて、有名になりたいという欲求はもともと薄いけれど、音楽を聴いてもらいたいという気持ちはいつでもしっかり持っている。ネットには配信サービスによって無限と呼んでもいいくらいの楽曲の海が広がっていて、そこには毎週数千曲の新曲がアップされ、過去の膨大な名曲たちをいつでも聴くことができ
取材・執筆・編集:柳樂光隆 | 取材:江利川侑介 | 通訳・編集:島田愛加 ◉『Antonio Loureiro』(2010)◎『Antonio Loureiro』のコンセプトーーアルバム『Antonio Loureiro』(2010)のコンセプトについて聞かせてください。 13、14年前のことなので思い出しながら話すね(笑) アルバムには僕の作曲した作品の進歩が現れているんだ。2007年にBDMGインストゥルメンタル賞(ミナスジェライス州の作曲/編曲家向けコンクール)を受賞したので既にいくつかの曲はあった。でも、このアルバムは僕にとってはカンサォン(=歌のある曲)を作るキャリアの始まり。最後の楽曲を除くと全てに歌がある。 ーーソングライターとしてのアルバムだと。 それまでガットギターを使って作品を作っていたんだけど、この頃から作曲にピアノを積極的に使うようになった。 ピアノ、ギター、そし
平素よりNatureの商品・サービスをご利用いただき、誠にありがとうございます。 先日、2024年7月8日22:00より発生しましたシステム障害の原因と、再発防止および障害発生時の影響を最小限に抑えるための取り組みについてご報告いたします。 発生した事象と原因 今回のシステム障害は、Natureサーバー上のデータベースに対する書き込みリクエストが一時的に急増し、想定していたキャパシティを超えたため、書き込みリクエストにかかる時間が大幅に延びる事象が発生しました。 この結果、APIサーバーがダウンし、Nature Remoとサーバー間の通信を適切に処理できず、Nature Homeアプリからの操作ができない状態になりました。 その後大量のNature Remoからの再接続が発生しシステム全体に障害の影響が広がったことから、原因の特定と対処に時間がかかり長時間に及ぶ障害となりました。 今後の対
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く