You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに 最近コンソール上で動くテキストエディタを作ったので、その中で得たノウハウなどを記事にしてみます。 作ったのはこちら https://github.com/hatoo/Accepted (Rustで競技プログラミングをするために作ったエディタなので興味のある方は使ってみてください!) ですが、この記事では新たに簡単なテキストエディタを作ってみたいと思います! https://github.com/hatoo/kiro 参考文献 Build Your Own Text Editor この記事で作るもの ターミナル上で動くテキストエディタ 日本語対応 モードレス 状態の管理が面倒そうなのでVimとは違いノーマルモード、インサートモードなどのモードがないエディタを作ります 要はターミナル上で動く「メモ帳」です Rawモード 普通にコンソールプログラムを作って動かしているときの様子を思い出
このステージの詳細についてはThe TC39 Processを参照してください。 2ヶ月に1度行われるTC39のミーティングにおいて、プロポーザルごとにステージを進めるかどうかを議論します。 このミーティングの議事録もGitHub上のtc39/tc39-notesにて公開されています。 ステージ4となったプロポーザルはドラフト版であるtc39/ecma262へマージされます。 そして毎年の決まった時期にドラフト版を元にしてECMAScript 20XXとしてリリースします。 この仕様策定プロセスの変更は、ECMAScriptに含まれる機能の形にも影響しています。 たとえば、class構文の策定は最大限に最小のクラス(maximally minimal classes)と呼ばれる形で提案されています。 これによりES2015でclass構文が導入されましたが、クラスとして合意が取れる最低限の
SSRF(Server Side Request Forgery)という脆弱性ないし攻撃手法が最近注目されています。以下は、ここ3ヶ月にSSRFについて言及された記事です。 EC2上のAWS CLIで使われている169.254について SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例 SSRFを利用したメール送信ドメインの乗っ取り 「CODE BLUE 2018」参加レポート(岩間編) この「空前のSSRFブーム」に便乗して、SSRFという攻撃手法および脆弱性について説明します。 SSRF攻撃とは SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。 攻撃者からは、公開サーバー(203.0.113.2)にはアクセスできますが、内部のサーバー(192.168.0.5)はファイアウォールで隔離されているため外部から直接
以下の記事のアップデート版です。Jupyter が5系にバージョンアップしているのと、イメージが整理されています。 Jupyter の Docker イメージを使ってみる - Qiita Jupyter は Python のツールである IPython から出発しましたが、データ分析の過程を Web 上で共有できますので、R でも使われるようになり、最近ではHadoop基盤をバックエンドとして Spark との統合も進んでいます。 Numpy, pandas に代表されるように、データ分析に必要なライブラリは依存関係が複雑化してインストールに苦労することもありますが、Docker を使うことで実行環境のポータビリティを向上できます。また、実行環境をコンテナごとに分離できますので、Hadoop上でDockerを動かす仕組み (Docker Container Executor - Apach
この記事はリクルートライフスタイル Advent Calendar 2016の10日目の記事です。 DEPRECATED! [2020/12/05追記] この記事内のコマンドは現在のバージョンの挙動と一部異なっていたり、説明に不正確な部分があります。 例えば公式のチュートリアルなど、信頼できる情報を参照ください。 https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/ 2019/05/30追記 下記内容は若干の不正確を含みますので、軽く読み流して雰囲気を掴んでいただいたあとは https://qiita.com/Kta-M/items/ce475c0063d3d3f36d5d などご参照いただくとよいかと思います。 こんばんは 「sshするときの-p 443ってなんの数字ですか?」ぐらいの素人がインフラ周りを担当し8ヶ月、kub
最近 stress コマンドを使って,サーバに負荷をかける方法を紹介する機会があり,よく使っているのに今までブログに書いていなかったなと気付き,今回まとめることにした.CPU に負荷をかけるだけなら yes > /dev/null をコア数に合わせて並列実行すれば良いけど,stress コマンドならメモリとディスクにも負荷をかけることができるので,シナリオのバリエーションを増やすことができる. stress project page インストール 検証環境として CentOS を使った. $ sudo yum install stress $ stress --version stress 1.0.4 共通オプション 以下のような共通オプションが用意されている.よく使うのは --timeout で,秒数を指定して負荷をかけることができる.他はあまり使ったことがないかも. -t, --tim
リポジトリを横断しての開発 自分は普段いくつかの(主にマイクロサービス)リポジトリを横断しつつコーディングをしています。 その際に tmux + zsh + neovim を使っているのですが、 tmux (とzsh)を使って複数のリポジトリを横断する最高の設定を使っているので紹介します。 まず前提として、複数リポジトリのマイクロサービスを立ち上げるとめちゃくちゃコンソールが増えると思います。 自分はプロジェクト毎にローカルサーバで1-2個・エディタ1つ・シェルで1つ・REPLで1つくらいは平気で使います。ついでに一時的な検証をするワークスペースを作って5-7個くらいは平気でプロジェクトを横断することがあります。 これを tmux の window と pane だけで管理するのは辛いのでやめましょう。 tmux には session という便利な機能があるのでこれを使います。 簡単に説明
さくらインターネットのアドベントカレンダー9日目として、サーバ屋らしく、運用に関するコマンドの使い方を紹介します。 サーバの負荷が高まってきたときに、vmstatやtopなどのコマンドで調査する事が出来ますが、I/O負荷をwa(iowait)によって判断する人も多いと思います。 ただ、結論から言うと、iowaitは正確にI/Oの負荷を表しているわけではありません。 これらを、実際に演習をしながら見ていきたいと思います。 iowaitとidle iowaitとはあくまでも、CPUが空いているのにI/Oがボトルネックになっているプロセスを示しているだけで、CPUの利用率が高いときにはI/Oがボトルネックになっていてもiowaitが上がりません。 同様に勘違いされがちなのが、id(idle)はCPUの空きを示しているというものですが、idleは必ずしもCPUの空き時間を示しているものではありませ
訳あって(後述)、シェル上でターミナルの256色を24bitのRGBコードへ変換する必要が出てきました。 ここではその手法をメインに、ターミナルの256色について調べたことを書いてみました。 定義区分について これら256色は全体で統一された規則によって定義されているわけではなく、3つの異なる定義方法で分けられる領域があるようです。 システム用パレット(0 ~ 15) 有彩色(16 ~ 231) 無彩色(232 ~ 255) 基本の16色パレットは今回置いておくとして1、問題なのは16から231までの「有彩色ゾーン」、232から255までの「無彩色ゾーン」。 こいつらの変換方法を確認しておきましょう。 有彩色ゾーンについて まず以下の連立方程式を満たす、色インデックス( $i$ )に対応する三原色の色レベルを算出します。 \begin{eqnarray} \left\{ \begin{ar
Here at Stream, we use Go extensively, and it has drastically improved our productivity. We have also found that by using Go, the speed is outstanding and since we started using it, we have implemented mission-critical portions of our stack, such as our in-house storage engine powered by gRPC, Raft, and RocksDB. Today we are going to look at the Go 1.11 compiler and how it compiles down your Go so
Transcript Go Ͱ Network Programming ͢ΔͨΊ ͷΑ· Tomohiro Takezawa ࣗݾհ • ᖒ ༑ത • Github: ttakezawa • Twitter: @takezawa • גࣜձࣾKyashॴଐ • όοΫΤϯυશൠ • ಛʹ VISA QUICPay (Google Pay) ͷϓϩηγϯάγεςϜͳͲ ࣮ͱωοτϫʔΫϓϩάϥϛϯά • ࣮ࡍͷͱ͜ΖɺࣄͰ͏ػձ͋Δʁ • Kyash ͷۀͰඞਢͳͱ͜Ζ͕͋Δ • ΫϨδοτΧʔυͷϓϩηγϯάۀ • ϨΠϠʔͷཧղ͕ਂ·Δͱڧ͍ ͢͜ͱͱɺ͞ͳ͍͜ͱ • ͢͜ͱ • ιέοτϓϩάϥϛϯάશൠ • Go ʹ͓͚Δ I/O ͷΈ • ͞ͳ͍͜ͱ • HTTP • νϟωϧ ࠓͷΞδΣϯμ • ωοτϫʔΫϓϩάϥϛϯάͷجຊతͳΠϯ
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ?」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
------- GND -- |01 31| -- +5V CPU A11 -> |02 32| <- M2 CPU A10 -> |03 33| <- CPU A12 CPU A9 -> |04 34| <- CPU A13 CPU A8 -> |05 35| <- CPU A14 CPU A7 -> |06 36| <> CPU D7 CPU A6 -> |07 37| <> CPU D6 CPU A5 -> |08 38| <> CPU D5 CPU A4 -> |09 39| <> CPU D4 CPU A3 -> |10 40| <> CPU D3 CPU A2 -> |11 41| <> CPU D2 CPU A1 -> |12 42| <> CPU D1 CPU A0 -> |13 43| <> CPU D0 CPU R/W -> |14 44| <- /ROMSEL (/A
builderscon 2018 の 9/7 セッションのスライドになります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く