タグ

2017年10月12日のブックマーク (5件)

  • 米、ユネスコ脱退表明=「反イスラエル姿勢」理由に:時事ドットコム

    米、ユネスコ脱退表明=「反イスラエル姿勢」理由に 【ワシントン時事】米国務省は12日、米国が国連教育科学文化機関(ユネスコ、部パリ)を脱退すると発表した。ボコバ事務局長に通告した。国務省によると、脱退は2018年12月31日付で、それ以降はオブザーバー国家としてユネスコとの関係を維持する方針。「機構改革の必要性や反イスラエル的な姿勢」を脱退の理由としている。「米国第一」を掲げるトランプ政権が国際社会に背を向ける姿勢が改めて鮮明となった。 イスラエルもユネスコ脱退へ=米国に追随 米国は11年にパレスチナがユネスコに正式加盟した際、パレスチナが正式加盟した国際機関への資金拠出を禁止する国内法に基づき、分担金の拠出を停止。米国の分担金はユネスコ年間予算の約22%を占めるため、ユネスコの運営は打撃を受けてきた。 米国は1984年にユネスコの放漫財政などを批判して一時脱退し、2003年に復帰した経

    米、ユネスコ脱退表明=「反イスラエル姿勢」理由に:時事ドットコム
  • 日本が機械学習パラダイスなのは情報大航海プロジェクトのおかげ - kuenishi's blog

    人工知能じゃ〜これからはシンギュラリティじゃ〜と盛り上がっており、も杓子も深層学習で人工知能で人類皆失業などと楽しいお祭り、ぼくは嫌いじゃない。我々が生きていくためには金が必要なんだ。というわけで、ちょっと気になって調べたことがあったのでここに記録しておく。もしこれが知財や法曹方面の業界で有名な話だったらコンピュータエンジニアたち何やってんのという話ではある。 AIブームというやつが燃料になって日機械学習パラダイスだという記事が話題になっているが、これは平成21年の著作権法改正で追加された著作権法47の7のおかげである(ラッキー!) じゃあ、そもそもどうしてそんな条項ができてるの? 調べてみたら情報大航海プロジェクトが深く関わっているようだよ?ちょっとは感謝したらどう?? もともとこれが気になっていた。ので調べました。という話。 著作権法の47の7が、思いがけず今重要にって解説が散見

    日本が機械学習パラダイスなのは情報大航海プロジェクトのおかげ - kuenishi's blog
  • システム刷新に失敗した京都市、ITベンダーと契約解除で訴訟の可能性も

    京都市は2017年10月11日、NEC製メインフレームで稼働している基幹業務システムの刷新プロジェクトについて、バッチ処理プログラムの移行業務を委託していたシステムズ(東京・品川)との業務委託契約を解除したと発表した。作業の遅れで京都市は既に稼働時期を2017年1月から2018年1月に延期していたが、それがさらに遅れて2020年になる見込みである。新システムの稼働時期は、当初予定よりも3年以上の遅れとなりそうだ。 京都市は2014年から81億円を投じて、国民健康保険や介護保険といった福祉系のほか、徴税、住民基台帳の管理など18業務を担っている基幹系システムの刷新プロジェクトを進めてきた。現行システムは30年前に稼働し、COBOLで構築している。 既に京都市は、福祉系のオンライン処理の刷新を予定通りに終了させている。地場のITベンダーなど5社が落札し、COBOLプログラムをポルトガルのアウ

    システム刷新に失敗した京都市、ITベンダーと契約解除で訴訟の可能性も
  • JUnit5で変わるテストの書き方 - きしだのHatena

    JUnit5が案外よさげなので、JUnit5を使うとどんな感じでテストが変わるのか考えてみます。 実際にどこが変わったかとか、使い方自体はいろいろまとめられたブログがあるし、公式ドキュメントも読みやすいのでそちらを。 http://junit.org/junit5/docs/current/user-guide/ メソッドごとのテスト JUnit5でいいのは、Nestedですね。 いままで、いろんなメソッドを対象にしたテストが入り混じってたと思います。 import org.junit.Before; import org.junit.Test; public class PurchaseTest { @Before public void setup() { // 全体のセットアップ // purchase()用のセットアップ // history()用のセットアップ } @Test p

    JUnit5で変わるテストの書き方 - きしだのHatena
  • デスマサバイバルガイド | さにあらず

    はじめに#僕がよく知っている業界は SI だが、これに限らずソフトウェア開発の現場には、過酷な現場…いわゆるデスマーチが多いと言われている。 一方で、そのような過酷な現場を渡り歩き生き残ることでしか、良いプログラマになる方法は無いと言った考え方もある。僕の個人的な経験則からすると、この理屈はある程度合っていると思う反面で、合っていて欲しくないという気持ちは強い。 高い技術力をもつプログラマの全てがデスマ職人という訳ではない。 デスマーチに巻き込まれたと気が付いた時の妥当で基的な戦術は撤退戦だ。何か理由をつけて逃げ出すのが望ましい。つまり、休職なり退職なり、異動なりして、その職場から離れるのが望ましい、出社拒否も良い。しかしながら、何か様々な理由があって、そこから逃げ出せないことはあるだろう。 僕はもう長い事デスマーチに関わることなく生きられているが、徐々に忘れつつあるので、若いころに獲得

    デスマサバイバルガイド | さにあらず