eDP-1 connected primary 3200x1800+1920+0 (normal left inverted right x axis y axis) 294mm x 165mm HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 267mm eDP-1というのがxps-13のディスプレイで、HDMI-1が外部ディスプレイのことです。 外部ディスプレイを左側に置いているので、xps-13の設定が 3200x1800+1920+0 になります。 x座標が1920、つまり外部モニタがFulHDなのでその右側に位置させたいのなら、このような値になる、ということです。 スケーリングの値を変更する まずは外部モニタの解像度を本来のFullHDにしたいので、次のように打ちます
sshは通るけどcloneはできない あると思います。そんな時のためのメモです。 Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. これですよね。 ssh-keygenでid_rsa以外を指定 ssh-keygenした時にkeyのファイル名を変更していると上記のエラーが出ると思います。(たとえばgithub_id_rsa, github_id_rsa.pub のように) GitHubのSettings⇒SSHで公開鍵登録しても、 sshは通るけど、cloneはできないという状態になると思います。謎。 この場合は、ssh-addをする
Bitbucket上に作ったプライベートリポジトリを、ローカル環境に初めて clone するときに Permission denied って言われる。 [sseze@centos63 ~]$ git clone git@bitbucket.org:sseze/**********.git Initialized empty Git repository in /home/sseze/**********/.git/ The authenticity of host 'bitbucket.org (207.223.240.182)' can't be established. RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40. Are you sure you want to continue con
概要 chainerのmodel(Chainクラス)を入れ子にして使っていたら重みが更新されなかった. Chainクラスで重みの更新がされるのは self.init_scope()内に書いている linkオブジェクトだけだったことが判明し, with self.init_scope():以下に書くとちゃんと更新された. 状況 version chainer==3.0.0 やりたかったこと あるmodelAに layerNを追加して,新たに modelBを作成したかった. だめなコード 計算グラフを出力すると,ちゃんとmodelA -> layerN という風に接続されていたので,これでうまく接続されているものだと思っていた. が,実際に学習中に都度重みを出力してみると,modelA内の重み(l1, l2, l3の重み)が全く更新されていないことがわかった. # example/train_
「ちまちま削除する」なので、トランザクションでAll or Nothingを保証したい場合は使えない。 id をプライマリーキー(ただしサロゲートキーかどうかは問わない)、 hoge, last_update が本来消し込みに使いたいカラムだとする。 プライマリーキー(またはユニークキー)がないテーブルのことは考えない。 KEY(hoge, last_update) がある場合 ターゲットのプライマリーキーを取り出して DELETE .. WHERE id IN .. の形に落とし込む 行ロックに落とし込める idの型を選ばない(varcharだろうと使える) 自前でINリストを作るのが面倒ならGROUP_CONCATという手もあるけどその場合は group_concat_max_len に注意 DELETE の方でもとの条件をANDしておくのを忘れると事故ることがある。。 けどあんまりI
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。
マネーゲームとしての仮想通貨は興味はないのだが、技術的に興味があって自分で簡単なコードを写経しながら勉強した。 定義 ブロックチェーンの実体はブロックを繋いだリスト構造 ブロックはいくつかの入力値(生成日時など)と、自分自身のハッシュを持っている 前のブロックのハッシュ値と、入力値を元に自分自身のハッシュが決まる。その手順は公開されている。 要はハッシュ値とそのメタデータが連続するただの配列なりの LinkedList。面白いのはここから。 ネットワークに参加するそれぞれが任意に新しいブロックを追加することができる ブロックチェーンは検証結果が正しく、より長いものが信頼される なのでビットコインみたいな仮想通貨は、生成コストが重く、検証コストが軽いものが好まれる。 他のネットワーク参加者からブロックチェーンの更新を受け取った時、手元のブロックチェーンとそれを比較し、より長いものを自分のブロ
あなたが通っているクリニック、大丈夫ですか? 私は5年前、医療事務としてクリニックで働いていました。 そのクリニックを辞めた理由は、「怖かった」から……。 え?何が怖かったのかって? まあ、その前にクリニックについて先に少し説明しておきます。 某クリニックについて 私の勤務していたクリニックは、医師1名=院長がトップに君臨するワンマンクリニック。 医療事務が3名(+派遣1人)、看護師が1~2名の小さな職場でした。 制服は看護師さんも医療事務もみんな同じ。 白いナース服にピンクのエプロンとカーディガン。 毎日コスプレw とにかく、院長の言うことには絶対服従。 それが原因か、私が働くことになった時には医療事務は一気に退職した後で、残っていたのは看護師1名のみ。 しかも、この看護師さんも引き継ぎのために残ってくれただけで1か月後には退職予定。 ヤバい職場環境、間違いなし! 院長は、病気(症状)に
はじめに NagisaでiOSエンジニアをしている伊藤です。 今回はReactNativeというスマホアプリのクロスプラットフォーム開発ツールを使った取り組みについて紹介をしたいと思います。 アプリのクロスプラットフォーム開発といえば、以前ではTitaniumやCordovaといったWebViewをベースとしたアプリをイメージするものが多く、純粋なネイティブアプリに比べるとどうしてももっさりとした感覚になってしまい、あまり採用されることはなかったように思います。 ReactNativeではこのもっさりとした感覚はなく、とてもスムーズに動作するアプリを作れます。その理由はWebViewを使用せず、ビューやラベル、スイッチなどで本当のネイティブコンポーネントを使った画面が構成されるところにあります。これにより国内でもにわかに人気が出てきています。 UPTOON!のReactNative化 UP
NAMは2017年12月24日から2018年1月31日までの39日間、ICO(イニシャル・コイン・オファリング=仮想通貨技術を使った資金調達)を実施し、国内外から100億円の資金調達を目指すと発表した。 医療の見地を持ったAIのエンジニア集団 同社は、10月に創業したベンチャー企業だ。NAMの名称は、代表取締役である中野哲平氏の名字を用いたNakano AI Medicalの略という。 社員15名の研究者・エンジニア集団で、中野氏は2017年に慶應義塾大学医学部を卒業したばかりの25歳だ。2016年、2017年に経産省所轄IPAの未踏事業に事業採択されており、それらの事業を独立して行うプロジェクトという。 NAMは、「医療の見地を持った、人工知能に関するエンジニアのプロフェッショナル」と説明する。今後予定している医療業界向けAIサービスの研究開発費用やクリニックの開業に向けた調達のため、
最近、Webサイトの高速化が話題になっています。 Wantedlyでもサーバーサイドのレスポンス速度はしっかりトラッキングして取り組んでいましたが、フロントエンドはまだまだやれることがあると認識し、悔しさを胸にさっそく動き出しています。 取り組むに当たって、まずは事例を集めていくことから始めました。サーバーサイドの実装を見ることはできないですが、フロントエンドは頑張れば覗けるので、Webサイトの高速化に取り組んでいそうな他のサービスをじっくり観察することで、自分たちのプロダクトに最適な方法を選択できるはずです。 様々な種類のサービスを提供しているサイトを調査してみると、その高速化の手法はサービスごとに結構違っていて、学ぶことが想像以上に多かったので、ブログにまとめてました。同じようにWeb高速化へのモチベーションが高まっている皆さんの参考になれば幸いです。 Netflixまずは、動画ストリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く