サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
そもそも既存はどんなロジック？RDBなんだからWhere句使ったら？ なぜファイルにすると速くなるのか？ 並列化と分散処理による高速化の可能性COBOL使う必要あったの？Javaとかじゃダメだったの？ まとめ TLを見てると以下の記事が少し話題になってました。tech.nikkeibp.co.jptech.nikkeibp.co.jp 対象の記事は有料会員じゃないと見れないのだけど事例としては以下みたい。 リソース - ユーザー事例 -COBOL製品 ユーザー事例 : マイクロフォーカス さて、この記事の驚きポイントは「１億レコードくらいのDB処理をRDBからCOBOL +CSVに変更してUnixサーバからWindowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。 「せっかく7割もあったSQLを全部COBOLに変えるとか時代に逆行しすぎ！」
技術的なお問い合わせに関するガイドラインAWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。本ページでは、お客様が技術的なご質問をサポートケースに起票いただく際に、早期解決に役立つポイントをまとめました。例文も掲載していますのでぜひご参照ください。 なお、サポート全般についての一般的な情報は、AWS サポートをご参照ください。 サポートレベル毎の技術サポートへのアクセスについては、AWS サポートのプラン比較をご参照ください。Note: The English version is the informal translation of theJapanese versionGuidelines (技術的なお問い合わせに関するガイドライン). Multiple customers in Japan requested us to provide English version. We ho
エンジニアのjhondaです。入社して1年が過ぎました。 ターミナル上での開発作業が好きなので開発を快適に進めるために常日頃から使っているツールやエディタを抜粋して紹介します。 この手のツールは組み合わせることで更に便利になるので、組み合わせを含めた紹介となります。 筆者の会社での開発環境はMacですが、プライベートマシンのLinux上でも同じものを使えています。 筆者のターミナル環境は Alacritty + tmux です。 AlacrittyRust製ターミナルエミュレータ。GPUを使うので描画が高速。 https://github.com/jwilm/alacritty 同リポジトリよりRust製だからという理由なので趣味です。でもたしかに速い気がします。 tmux 言わずとしれた仮想端末エミュレータ。 https://github.com/tmux/tmux たいして使いこな
もしかしたら私だけかもしれないです。ずれているかもしれません。 一般論ではないかもしれません。 でも、同じような気持ちになっているエンジニアがいるかもしれないので、 代表して言わせてください。エンジニアに、気軽に「バグ」と言うのをやめませんか？ 最近立て続けに以下のようなことが起こっており、私と同僚が消耗しています。心がすり減ってます。ワーカーエクスペリエンスが低下しています。。。 ～～～～～～～～～～～～～～～～～～～ 「○○さん、この数値がバグなんだけど直してもらえる？」 →調べたらその週は祝日影響で、営業日が少ないだけだった。 「あのデータのバグはいつ直りますか？」 →データの集計定義の変更の依頼があり、変更前の状態をバグと呼ぶ 「この前入ってなかったバグなんだけど、次の開発に入れてもらっていい？」 →スコープ外のこと（担当がそれを忘れていた）をバグと呼ぶ ～～～～～～～～～～～～
Inside Frontend #2 の発表資料です https://inside-frontend.com
技術的な標準・規格 (TODO: IATA,Microsoft) tzdatabase タイムゾーンに関する、ソフトウェア・エンジニアにとって最も標準的なデータが tzdatabase (Wikipedia) でしょう。 "Asia/Tokyo" や "Europe/London" のようなタイムゾーンの名前は、この tzdatabase のものです。 tzdatabase のタイムゾーンは "/" の前の最初の部分に大陸名・海洋名を用い、続いて、典型的にはそのタイムゾーン内の著名な都市名・島名をその代表として名付けられています。21 国名は基本的に使われません。22 "America/Indiana/Indianapolis" のように3要素で構成されるタイムゾーンも少数ながら存在します。 tzdatabase はボランティアによってメンテナンスされています。タイムゾーンの情
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
ウェブフロントエンド技術は変化が激しいと言われるけれども、多くの人にとって最新のウェブフロントエンド技術を無理してキャッチアップする必要は無い。以下理由。 ここでいう最新のウェブフロントエンド技術とは、新しいブラウザのAPIや新しいJavaScriptの文法や新しいフレームワーク・ツールなどを指す 今のHTML5はドキュメントを表現するプラットフォームだけではなくアプリケーションプラットフォームとしても機能するように進化をしている最中 だからアプリケーションプラットフォームとしての進化を支える新技術がたくさん出てきている 逆に言うと、アプリケーション(SPAとか)を書かない人にとってはキャッチアップする必要の無い場合がたくさんある また、それらのウェブフロントエンドの新技術を全てキャッチアップするのは基本的に不可能だと思う 自分はウェブフロントエンドやそれのパフォーマンスを専門の一つにして
このページはC++17に採用された言語機能の変更を解説しています。 のちのC++規格でさらに変更される場合があるため関連項目を参照してください。 概要C++17ではbool型に対する前置および後置のoperator ++を削除する。 bool型に対する前置および後置のoperator ++とはC++98の時点で非推奨になっていた機能である。 具体的にどのような働きをするのかというと、以下のように値をtrueに書き換える機能をもつ。 #include <iostream> int main() { bool b = false; const bool b1 = ++b; std::cout << std::boolalpha << b1 << std::endl; // => true const bool b2 = ++b; std::cout << std::boolalpha <<
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。Simon Brown 始めに マイクロサービスの利点と欠
フロントエンドエンジニアの渡辺です。 業務委託で働いてる身ですが記事書くことになりました。懐深い。 先日「ESLintのルール設定を全て確認して設定をする」ということをしました。 （ESLintはv4.0.0時点で240以上の設定項目があります。） 普段はルール設定が膨大なので必要な項目しか見ないのですが、 全てに目を通してみると得られた知見が多くあったので共有します。 設定方針 まず、ESLintの膨大なルール設定をどう設定するかを決めます。 やり方は大体3パターンに分類できます。 緩いルール設定（eslint:recommendedなど）を元に、設定を足して厳しくする。 厳しいルール設定（airbnbなど）を元に、設定を引いて緩くする。 既存のソースコードを解析し、ESLintの機能でルール設定を自動生成する。 今回は「入れたいルールに絞って設定したい」という思いがあり、 eslint
Rebuild.fm の mirakui さんの回聴いてたんだけど、インフラの世界観だと、ロックインさせたいAmazon/Google VS 自由を手に入れたいDocker みたいな構図がある、な話があって、思うところがあった。 rebuild.fm 勿論、話はそう単純じゃないし、それぞれがそれぞれの成果を利用しあってるので、どっちが正義だみたいな話にはならない。第三者目線としては、寡占にならず競争が続くのが望ましい。僕個人の意見としては、金が生まれるところには、正しく金が生まれてほしい。それで全体としての健全性が育まれるなら。日本にいてあんまり面白くないのは、その辺の基盤技術に関われる機会があんまりないことだが…。 とはいえ、利用者目線としては、できるだけ自由なポジショニングを可能な限り選び続けるべき。だが、自由を手に入れるには、それだけの知識が必要となるし、そこを諦めたところをアウト
オープンソースからハイスクールフリート、The Beatlesまで何でもありの自称エンターテインメント日記。 最近TransifexとかLaunchpad (のRosetta)とかPootleなどなどを採用し、オープンソースソフトウェア(OSS/FLOSS)の翻訳がWebでできるようになっています。 同時にWebの翻訳サービスも多数存在し、どんどん精度が上がってきています。 ではWeb翻訳の結果をOSS翻訳に突っ込めばいいのではないかというと、それは違います。Web翻訳にも当然利用規約があり、そのようなことは禁止されてることが多いです。世の中すべてのサービスのライセンスを確認するのは不可能ですが、概ねその傾向にあるのは事実でしょう。具体的にはExcite翻訳の利用規約だと第6条で明記されています。 OSSの翻訳にするということは、そのOSSのライセンスに従うということで、それは > 私的利
つまり、これらのマーケットは小さく、しかもデータベースのマーケット自体よりも小さいのです。とは言え、どれかが他よりもマシになりうるでしょうか？ マネージドホスティングは、本質的にはユーザのためにAWSでデータベースを動かすことで、そうすることでユーザたちは自分で動かす必要がなくなります。これらのサービスを使う代わりになるのは、AWSに自分でデータベースを立てることです。したがって、マネージドなデータベースホスティングサービスが課金できる額には、非常に厳しい上限があることになります。Compose.ioやmLabが、RethinkDBよりも1桁あるいは2桁多いユーザを抱えるMongoDBを提供していることを考えて、マネージドホスティングを提供することには少しの良い点もないという結論を下しました。Database as a Serviceはマネージドホスティングの更に複雑なバージョンです。D
エグゼクティブサマリGoDaddy社の発行するドメイン認証SSL証明書に認証不備の脆弱性があり、予防的な処置として8850件の発行済証明書が失効された。これは同期間に発行された証明書の2%未満である。現在は脆弱性は解消されている。 概要GoDaddy社は米国のホスティング（レンタルサーバー）やレジストラの大手で、認証局（CA）の事業も手がけています。GoDaddyが発行するドメイン認証証明書の認証手続きに不備があったとして報告されています。 In a typical process, when acertificate authority, likeGoDaddy, validates adomain name for an SSLcertificate, they provide a random code to the customer and ask them to p
ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら
はじめに こんにちは、大正デモクラシーです。年末年始に実家に帰るにあたって、Windows 10がインストールされているXPS 13を持って行ったんですが、実家で庭木の剪定以外にやることがなかったので、それ以外の時間はずっとコード書いてました。しかし、持って行ったマシンの開発環境がまったく整ってなかったのでいろいろ設定しなおしてとりあえずいい感じになったので、その作業メモを書いておきます。 TL;DR これまでLinuxやmacOSで育ててきた環境をWindows 10で使うことはあきらめて、これらのツールをとりあえず入れました。 cmder | ConsoleEmulator Chocolatey - The package manager forWindowsGitHub -Microsoft/Git-Credential-Manager-for-Windows: Secure
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
