Зміст презентації полягає у тому,щоб зберегти людину від впадання в депресію.Кожен може знайти у ній корисну для себе інформацію.
Dockerとは コンテナベースのアプリケーションを仮想化したもの。軽量なVMの様に見えるがこれまでの(VirtualBoxなど)VMでは実現が難しい、不可能であったユースケースを解決してくれる。 ホストOSとリソースを共有するのでリソースの管理がVMより効率的 基本的に状態を持たないのでポータビリティが非常に高く、特定の環境に依存することがない 軽量なのでVMと比較し複数のインスタンスを実行することができる DockerHubなどのレジストリを利用することで既存のイメージをダウンロードして実行することができる コンテナとVM VM VMはハイパーバイザを通してホストOSに対してのシステムコールを解釈させるなどの必要がある それぞれのVMには全て独立したOS・アプリケーション・ライブラリが必要 コンテナ ホストのカーネルは実行されるコンテナと共有される(コンテナは常にホストと同じカーネルを
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
Pythonプログラマーというか、元々Python(ときどきR、C言語)で数値シミュレーションをしていた学生が、就職してRubyでWeb開発を行うにあたって勉強したことを書き連ねていくだけの記事です。 もし自分と同じような立場の人(これから後輩としてもどんどん増えていくかも!)がいたら、「ここを押さえておけばRubyは問題なく書けるよ」と教えられるように書いておきます。というのも、レビューを行っていた先輩とのプログラミングのスキルとの開きがあり、先輩も私も「どこが分かってないのか説明できない」状態になってしまってお互いに困ってしまった経験があるからです。 RubyとPythonはよく似ているのですが、思想や見た目で違う部分が多く、片方を勉強するともう片方の理解も深まります。 たまに2ちゃんねるのオカルト板である「見たことある世界によく似た異世界に迷い込んだ」みたいな感覚で、なかなか面白い経
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit(GitHub)をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです! ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と5つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
まず、私が先日公開したブログ記事 (英語) に寄せられたあるコメントを紹介しましょう (たくさん寄せられたうちの 1 つで、その記事のコメント欄でご覧いただけます)。 Btw, "until I realized that the Solution Explorer tree nodes are searchable." This one is a saver ! (訳: ところで、「ソリューション エクスプローラーのツリー ノードが検索可能…」と書かれてていますが、こういうヒントは助かります!) この記事の中で何気なくソリューション エクスプローラーのテキストが検索可能であることに触れたのですが、それがコメントの投稿者である Sam さんの目に留まったようです。このようなちょっとした小ワザは Visual Studio にたくさんあり、中には熟練の開発者ですら知らないものもあります。こう
Weather radar, wind and waves forecast for kiters, surfers, paragliders, pilots, sailors and anyone else. Worldwide animated weather map, with easy to use layers and precise spot forecast. METAR, TAF and NOTAMs for any airport in the World. SYNOP codes from weather stations and buoys. Forecast models ECMWF, GFS, NAM and NEMS
こんにちは。ヨッピーです。 普段は主にインターネットで風俗の話などをしております。 さて、「PC DEPOT」(以下PCデポ)という神奈川県を基盤に、主に首都圏でパソコン販売事業などを展開する小売店が、80歳を超える高齢者に対して月額15,000円弱という高額のサポート代を含む契約を結び、親族がその解除を求めたところ、契約解除料として20万円もの大金を請求するという事案が発生し、インターネットは元より、テレビ番組でも報道されるなど大きな話題を呼んでおります。 当初、20万円の解約料を請求されたのは事実です。これが20万円の根拠のようです。フォロワーさんから教えていただきましたが、解約料に消費税はないみたいです。 何から何まで悪質です。 出典:ケンヂさんのTwitterより 騒動の発端となった、契約者の息子である「ケンヂ」さんのツイート。 契約解除料108,000円のレシート※若干画像の明る
XFSは、巨大ストレージでの利用を視野に入れた64bitファイルシステムである。膨大な領域を効率的に利用するため、XFSにはさまざまな仕組みが組み込まれている。(編集局)
こんなことを想像してみてください。 あなたは大企業で働いています。仕事はかなり退屈です。端的に言えば、あなたの顔も見たくないという経理担当の3人しか使わないようなアプリケーションのために定型的なコードを書いて、才能を無駄にしているという状況です。 あなたが本当に情熱を注げるのはセキュリティです。毎日、 r/netsec を読み、仕事の後にはバグ報奨金プログラムに参加しています。ここ3カ月間は手の込んだ株式取引ゲームをプレイし、報奨金を得ています。ヒープベースのバッファオーバーフローを発見し、優良株を選ぶ手助けとなるAVRシェルコードをいくつか書いたからです。 あなたが取り組んできたビデオゲームが、実は巧妙な偽装のリクルートツールであったと判明し、全てが変わります。世界最高のセキュリティコンサルタント会社、Mont Piperが人材を募集していて、あなたは面接に行くことになったのです! 飛行
(訳注:2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) ことの始まりは、あるスパムキャンペーンでした。画像1は、スパム向けに仕掛けた罠に最近引っかかった、疑わしいドキュメントファイルが添付されたメールです。文面の英語がとても稚拙なことに気付くかと思いますが、この稚拙さがメール受信者への警告サインとなります。 画像1:スパムサンプル 添付のファイルは、”.doc”のファイル拡張子を使っていますが、実際はRTF(リッチテキストファイル)ファイル形式で、特別に細工されたRTFファイルによるスタックオーバーフローの脆弱性が含まれています。この脆弱性は、CVE-2010-3333で文書化されており、”pFragments”の形をしたプロパティを扱う際にMicrosoft Word RFTパーサを攻撃するものです。これに対する修正モジュールは5年以上前にパッチされています
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS(Hypertext Transfer Protocol Secure)は、HTTPによる通信を安全に(セキュアに)行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
Linuxを強制終了しないといけないことがある。 暴走したり、動かなくなったり、プロセスがおかしくなったりパターンは様々だ。 このページではLinuxの強制終了の方法をまとめてみた。強制終了をしなければならなくなったとき、参考にしてほしい。 プロセスを強制終了する プロセスが止められなくなることがある。WindowsでもMacでも同様のことはよく起こるはずだ。 こういったプロセスをユーザは意図的に止めることができる。これを「プロセスを強制終了する」という。また物騒だが「プロセスを殺す」ともいう。 killコマンド 「ps aux」や「top」コマンドなどでプロセスを確認するとそのプロセスがどの程度リソースを消費しているか? ゾンビプロセスになっていないか確認できる。「top」のほうがリアルタイムに監視可能なのでこちらを使うとわかりやすいだろう。 暴走しているプロセスがあったらプロセスIDを
要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法(例あり)、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは? 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ(MSR) アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3
ここで論じているのは、オーディオアプリの開発者が陥りがちな 4つの間違い 、 より良く開発する方法 、 問題個所の発見方法 です。主に開発者向けの内容ですが、開発者以外の方にも知っておいてもらいたいと思います。ここでは、開発者向けの診断ツールである Realtime Watchdog を紹介し、 人気のあるオーディオライブラリの調査結果 を提示します。 オーディオアプリの開発はとてつもなく楽しいです。やりがいを感じるし、創造力を発揮できる範囲が大きく広がり、ひとたび開発が終われば、 誰かがクリエイティブなツールとして使ってくれるのです! こんな分野は多くないし、この領域で働けるなんて非常に幸運だと自分でも思っています。 しかし、仕事でオーディオアプリを扱う時には深く考えなければならない部分もあります。オーディオアプリの開発者としてユーザに対する責任があるのです。大前提として、ユーザを公共の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く