Androidの開発へ「Rust」を導入、なぜなのか
2021年4月6日（米国時間）、Googleは公式ブログでAndroidオープンソースプロジェクト（AOSP）がモバイルデバイス向けオープンソースOS「Android」の開発において、オープンソースのシステムプログラミング言語「Rust」の導入を進めていることを明らかにした。Googleは2021年2月に設立された独立非営利団体「Rust Foundation」にも加盟している。 Androidはこれまで、「C」や「C++」といったシステムプログラミング言語を用いて開発されてきた。Android開発にRustを導入した目的は、メモリ安全性のバグを予防することにある。 AOSPはこれまでもメモリ安全性のバグの検出や修正、軽減に注力してきたが、さらに予防を強化しようとしている。メモリ安全性を特徴とした言語の採用が、最も費用対効果の高い予防方法だとの認識から、Rustの導入に至った。 Andro
優秀さについて
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が
Java IDEの使いやすさはIDEがどのようにJavaを知ってるかで決まりがち - きしだのHatena
Java IDEにもいろいろあるけど、それぞれの特性としてIDEがどれだけJavaを知っているかということで決まるということをTwitterに書いたので、ちょっと具体的に書いてみます。 IDEの使いやすさについて、そのIDEがどれだけちゃんと言語を知っているか依存するんだけど、IntelliJ IDEAが一番Java言語を知っていて、NetBeansはJavaのエコシステムを知っていて、EclipseはJavaビジネスを知っている・・・ VS Codeはまとめサイトで見たレベルでJavaを知ってる感— きしだൠ(K8S(Kishidades)) (@kis) 2020年10月30日 ちなみに、全体としてNetBeans推しです。 使い分けとしてはこんなこと書いてます。 Java IDEの選び方 機能いらんけど使いやすくて安定したのがいい→IntelliJ IDEA CE 機能多いのがいいけ
西暦1年は閏年か？ - プログラマーの脳みそ
閏年（うるうどし）の話題。 Twitterで見かけた話題で「西暦1年は閏年かどうかぱっとわからん人おる？」という些か煽り気味のツイートを見かけたのだけども、反射的に「閏年じゃないに決まってるじゃん」とぱっと答えてしまわないだろうか。本当にそうだろうか？ そう単純な話なのだろうか？ プログラミングを学んでカレンダーを扱うことを学ぶ際に置閏法についても簡単に触れられることがある。置閏法というのは閏年や閏月（太陰暦では1年が13ヵ月になるケースがあり追加の月を閏月と呼ぶ）をどのようなルールで挿入するかという話で、まさにアルゴリズムであるからプログラミングの話題と相性がいい。 置閏法 現代の西暦の置閏法（ちじゅんほう）は 西暦を 400 で割り切れる年は閏年 上記以外で西暦を 100 で割り切れる年は平年 上記以外で西暦を 4 で割り切れる年は閏年 上記以外は平年 といった手続きで閏年（つまり2月
SpringでField InjectionよりConstructor Injectionが推奨される理由 - abcdefg.....
SpringでField InjectionよりConstructor Injectionが推奨される理由を調べてみたメモです。 (2016/12/30) サンプルコードにfinalをつけるように修正 (2017/03/29) Immutabilityについて追記 --- 家でも会社でもIntelliJを使って開発しているのですが、 Spring Bootで@Autowired(@Inject)を使うと下記のような警告が出るようになりました。 警告内容を見てみると、フィールドインジェクションは推奨されません、とのこと。 「Field injection is not recommended.」 警告の詳細を見てみると下記のように書いてあります。 「Field injection is not recommended. Spring Team recommends: "Always use
プログラミングを学ぶにあたって詰まったことと、そこから学んだこと - mizchi's blog
toyokeizai.net satoru-takeuchi.hatenablog.com 全然レイヤーが違うが、自分が何に悩んで、どういう風に理解したか、思い出しながら書き出してみる。 プログラミング歴 20歳からなので、現時点で10年ぐらいだが、中学生の時ちょっと触ったことがあった。 14 歳: 病気で入院したときに暇すぎて、2 週間ほど VBA を触った 大学 1 年: 大学の選択科目で Java, 夏休みに Python と Ubuntu の独習 大学 3 年: Python で自然言語処理のバイト 大学 4 年: Android アプリを作るバイト、就活ポートフォリオとして node/Websocket で MMO 一社目: Unity, ActionScript, Haskell, JavaScript 以降~: JavaScript/CoffeeScript/TypeScri
Reactor Core 2.5: もう一つのJava向けReactive Extensions実装 - Qiita
Reactive Extensionの調査中にReactor Core 2.5が面白いことに気がついたのでまとめ。 JavaDoc GitHub A lite Rx API for the JVM by Sébastien Deleuze (Spring I/O 2016での発表資料) Reactor Core (2.5) = Reactive Streams + Reactive Extensions(の一部) Reactor(〜2.0)は効率的な非同期プログラミングのためのツールキットで、基本的な関数型(Java8以前に開発されたため)に始まって高効率なスケジューラー上に実装されたReactive StreamsやそのReactive Extensions(Rx)、非同期のネットワークライブラリ等を提供していました。 ところがReactor 2.5を開発するにあたってプロジェクトの構成
Javaなら「この書き方がベスト」と信じて書ける - きしだなおきに聞く、Javaのこれまでとこれから｜ハイクラス転職・求人情報サイト AMBI（アンビ）
ハイクラス求人TOPIT記事一覧Javaなら「この書き方がベスト」と信じて書ける - きしだなおきに聞く、Javaのこれまでとこれから Javaなら「この書き方がベスト」と信じて書ける - きしだなおきに聞く、Javaのこれまでとこれから Javaは1995年に誕生し、数多くのコミュニティや企業の影響を色濃く受けてきました。では、黎明期から現代に至るまで、Javaはどのように進化し、生態系を変化させてきたのでしょうか。Javaのスペシャリストとして知られる、きしだなおきさんに聞きました。 1995年に誕生した、オブジェクト指向プログラミング言語・Java。この言語の歴史は、数多くのコミュニティや企業の影響を色濃く受けてきました。 例えば、OracleによるSun Microsystemsの買収後、Javaのリリースサイクルは大きく変化しました。また日本においては、JavaカンファレンスやS
「Rust」言語はCよりも遅いのか、研究者がベンチマーク結果を解説
「C」や「C++」に代わるシステムプログラミング言語として「Rust」が注目を集めている。メモリ安全性が高く、メモリ破壊バグといった脆弱（ぜいじゃく）性を作り込みにくいからだ（関連記事）。 ただし、システムプログラミング言語では、高い処理性能が必須条件であり、これがCやC++が使われ続けている理由となっている。Rustはどの程度「速い」のだろうか。 ドイツのミュンヘン工科大学で博士課程の学生であるポール・エメリク氏は2019年9月9日、Rustで作成したデバイスドライバの性能評価をGitHubで発表した。 同氏のグループはさまざまな言語で同じ機能を備えたデバイスドライバを記述し、性能を比較している。 何が性能低下を引き起こしているのか 性能評価用に作成したのは、Intelのイーサネットコントローラー向けのLinux用デバイスドライバだ（ixgbeタイプ）。 エメリク氏は解説の冒頭で研究に取
ArrayListじゃなくListを使うという話 - 日々常々
具象型ではなく抽象型で扱え、インタフェースを使え、みたいなお話に対して。 前置き Javaの話。他の言語だと話は変わります。 「こうするのが絶対的に正解」と言うものではありません。私の現在の選択の説明です。明日になったら違うこと言ってるかも。 主な登場人物は掲題の java.util.ArrayList および java.util.List、そして java.util.Collection と java.lang.Iterable です。 こんな世界観。他のインタフェースやクラスもたくさんありますが、この話の本筋では無いので触れません。 前提として以下を置いています。 フレームワークやライブラリではなく、一つの業務アプリケーションに閉じた話です。ゆえに不特定多数から使われる型ではなく、影響を与えるコードは全て目が届く範囲にあるものとします。 計算量は別の話です。扱うドメインにもよりますが、
過去のブーム（並列プログラム）の現状を考える
みんな割と未来の予言はよくするが、あんまりその結果を振り返らんよなぁ。 現在のディープラーニングのブームをどう捉えるか、というか、 プログラマのキャリアという点でどう接していくか、を考えるにあたり、 過去のブームを考えてみるのは良いんじゃないか、という気がした。 最近並列GCや並行GCの章を読んでいて、 一昔前の大きなブームとしてはParallel computingがあったなぁ、と思い出した。 ということでこの事について、専門にしてなかった部外者プログラマの目にどう映ったかを記しておきたい。 なお、「XXXだと言われていた」はあんまりソースとかを確認したりはしてません。 なんとなく自分はそう聞いていた気がしたしそう思ってた、程度のものです。 かつて思っていたことと当時の状況 Parallel computingはだいたい10年くらい前の時点ではその後の大きなトレンドとして明らかに存在して
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
Spring Bootアプリケーションのコードレビューポイント - Qiita
リクエストの入り口になるのはControllerになるため，初めてSpringを触る開発者の方も馴染みに深いと思うのですが，何も考えずにアプリを作っていくと，ついついControllerにビジネスロジックを実装してしまいがちです。そうすると，所謂保守性や可読性が低いFat Controllerが出来上がってしまうので，ビジネスロジックの隔離は強く意識したいポイントだと思います。 個人的にはそれぞれ以下の内容に徹するのが良いのでは？という考えです。 Controller リクエストの受付 リクエストパラメータのValidation Serviceの実行 例外処理 レスポンスの作成 Service ビジネスロジックの実行 外部サービスとの連携 Repositoryを介したデータ操作 トランザクション管理 Repository データ操作 Controllerの中で複数種類のServiceを呼び
ソフトウェアアーキテクチャの歴史 - tasuwo's notes
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か？何が正しくて何が間違っているか？も重要なのだが、それよりは、なぜそれが生まれたのか？何を解決しようとしたのか？どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか？を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
実践クリーンアーキテクチャ with Java - nrslib
この記事について こちらの記事はクリーンアーキテクチャの Java 実装による解説記事です。 MVC フレームワークに組み込むために一部変更している部分もあります。 それをふまえてご覧ください。 講演内容が @IT さまに記事にしていただけました。 あわせてご参照ください。 https://www.atmarkit.co.jp/ait/articles/1907/08/news002.html クリーンアーキテクチャよりも軽量で無理なく導入しやすいアプリケーションアーキテクチャパターンを考案しました。 https://nrslib.com/adop/ スライド JJUG CCC 2019 Spring での発表資料です。 この発表をするにあたって記事を書くことにしました。 YouTube YouTube でこちらの解説を行いました。 その他解説もしています。もしよろしければチャンネル登録を
英語の次はプログラミング、楽天の三木谷会長が社員に要求
英語を社内公用語にした楽天の三木谷浩史会長兼社長が、今度はコンピューターのプログラミング能力を社員に求めている。 近く１万7000人超の社員に、コンピュータープログラムの仕組みや、ＣＰＵ（中央演算処理装置）とＧＰＵ（画像処理半導体）の違いを理解するよう求める見通しだ。プログラミング言語を記述する初級レベルのコーディング能力が必須となる。 楽天は2018年、約260人の非技術系新卒者向けにプログラミング言語Ｊａｖａの入門レベルとネットワークアーキテクチャー構築の基本スキルを含む６カ月間のコースを設けた。今年４月入社の新卒400人も研修に３カ月を費やすことになる。同社では研修を全従業員に拡大する計画はまだないとしている。
Shibu's Diary: DeNAからフューチャーに転職して1年4ヶ月が経ちました
転職エントリーと退職エントリーは見かけるけど、途中の感想エントリーをみかけないので、つらつらと書き連ねたいと思います。だいたい1年4ヶ月ぐらい経って、一通り会社の雰囲気はわかって来たかなと。写真は五反田の西安飯荘の坦々刀削麺です。 http://blog.shibu.jp/article/181834465.html#more 仕事はFutureVulsの開発をちょびっとお手伝いしたのと、あとは客先常駐です。うちの会社では客先常駐は基本的に少なくて、打ち合わせはお客様のところにいくけど開発は自社に持ち帰って行う、ということが多いので、レアケースのようですね。自社の方が席が広かったりもろもろ快適ではありますが・・・今のお客様のレベルは高くて、他のベンダーさんからきている人たちのレベルも高くて良い感じです。エリートが揃っている感じ！ B2Bなお仕事はどうなのか お客様と直接お仕事をする一次受け
Go言語がダメな理由 | POSTD
私はGo言語が気に入っていますし、多くの場面で使用します。現にこのブログもGoで書いています。Goは便利な言語ですが、優れた言語とは言えません。つまり、悪くはないけれど、十分ではないということです。 満足できない言語を使用する際は注意が必要です。注意を怠ると、その言語を次の20年間使い続ける羽目になるかもしれないからです。 私のGoに対する主な不満を本文にまとめました。既に何度も指摘されていることも含まれていますが、中にはこれまでほとんど話題になっていない指摘もあります。 これから列挙する全ての課題には既に解決策があることを示すため、私が優良な言語と考えるRustやHaskellと比較して説明します。 汎用プログラミング 課題 誰でもさまざまな事柄に幅広く対応できるコードを記述したいと考えます。例えば数のリストの合計を求めるために定義した関数が、小数、整数、またその他の合計を求められるもの
Java 11 時代の Java プログラミングスタイルガイド - Qiita
Java のリリースサイクル が変更され、2019/01 現在の Java の最新バージョンは早 11。文法面での改善も進んでおり、モダンな Java のスタイルにも変化が見られる。この記事では Java 11 時代におけるモダンな Java プログラミングのスタイルをまとめてみたい。 筆者の主観を多分に含むため、その点ご注意を。 var（ローカル変数の型推論） var を積極的に利用する。 Java 10 で導入された var によるローカル変数の型宣言だが、基本的には使用できる場面では積極的に使用するというスタンスでよいだろう。モダンな言語の多くは同様の型推論を採用しているが、それで問題になったという話は聞かない。 高度に訓練された Java プログラマーにとっては左辺の型定義など IDE が自動補完してくれるので便利さを感じないという意見には一理あるのだが、コードを読むときに限っては
Arrays.asList(T... a) は、なぜ add や remove ができないのか？ - 地平線に行く
Arrays.asList(T... a) というメソッドについてググると、「このメソッドで返ってくる List は、add や remove ができないので注意しましょう」ということが良く書かれています。 でも、「なぜできないのか？」という点については書かれていないことが多いので、理由を説明します。 一言でまとめると「配列を List として扱えるようにラップするためのものだから」です。 （「変換するもの」ではないです） そもそも、どう使うもの？ 配列を List として扱いたいときに使います。 例えば、シャッフルするのに Collections.shuffle(List list) という引数に List を取るメソッドはあるのですが、引数に配列を取るメソッドがありません。 そういうときに、 Collections.shuffle(Arrays.asList(a)) という風にラップ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
