Mastodon という「自由で」「オープンソースな」（Twitter のような） SNS がなんか流行りだして、もともとあった mastodon.cloud や @nullkal 氏が立てたインスタンス mstdn.jp に日本人が多くあつまって祭りみたいになってる。 ASCII.jp：Twitterのライバル？　実は、新しい「マストドン」（Mastodon）とは！｜遠藤諭のプログラミング＋日記 API ももちろんあって、 .NET 製の APIライブラリもあった。 @kagasu さん glacasa/Mastonet: C# Library for Mastodonhttps://t.co/BwR9n1Eqbd — ♣ ♥ ♠ ♦🍍 (@kagasu) 2017年4月12日 で、試しにこの「Musto.NET」を使って、 mastodon.cloud の連邦？タイムラインを表示する

Go言語でGUIしたいかー？！　おー！！ とまあ、そんなノリで始まります。 Go言語でGUIするには？ Go言語でGUIするライブラリは意外と色々あります。 go-ui 「Go言語 GUI」でググった時に、おそらく一番情報の多いライブラリ。ただ情報はあるけど大して気合の入ったライブラリではない模様。 go-uiなんて大層な名前をしてるけど、その実態はQtバインディングだったりする。 開発はもう終わったみたいで、 GoQt というのが後継らしいけど、 GoQt の方はまだリポジトリを作っただけのような状態だった。 Windowsで導入するのがほぼ無理ゲー。（最重要事案） go-gtk mattn氏が開発の中心となっているGo言語のGtk+バインディング。多分Go言語のGUIライブラリで一番開発が活発。 Windowsでも動くらしいけれど、Win64な環境ではしったこっちゃないし、そもそもGt

こんにちは自動化エンジニアの水谷です。 最近業務でGo言語（golang）に触れる機会がありました。私がこれまで主に使っていたプログラミング言語は、C/C++やC#などが主で、あまり最近の（？）プログラミング言語には触れてこなかったのですが、Goはまだ新しく、名前も良く（個人的感覚）、プログラミング言語年収ランキングで1位を獲得したこともあることから、ちょっと気になっていました（ややミーハーですがｗ）。 Goは、デスクトップアプリやコマンドラインツールをはじめ、WebアプリのバックエンドAPIの開発や、モバイルを含んだクロスプラットフォームで動作するアプリの開発など、いろいろな用途に使われている言語ということで、この機会にGoがどんな言語でどんなアプリ開発経験（主にどれだけ快適に楽しく書けるか）が得られるのかを試してみたいなと思いたちました。 ということで、全く初心者の私が今回から数回に分

Pure Go library (no cgo) with a very simple API !!!

はじめに DockerやKubernetesを使ってマイクロサービスなどを構築する時には、必ずネットワーキングが必要になります。そのために必要な基礎知識をまとめておきました。 テーマは、 階層構造 プロトコルの詳細と通信の流れ MACアドレスとIPアドレス ネットワーク機器の種類 VLAN iptables network namespace です。 その１では、「ネットワーク機器の種類」までをまとめています。 ※DockerやKubernetesの話は出てきません。 ネットワークの階層構造 OSI参照モデル TCP/IP階層モデル プロトコルの詳細と通信の流れ L7とHTTP HTTP リクエストの種類とデータの中身 通信経路の確保 L4とTCP TCP ソケットの生成 データ保証と再送制御 フロー制御（流量制御） L3とIP IP TTL（Time To Live） L2とEthern

はじめに 前回は、Docker/Kubernetesを扱う上で必要なネットワークの基礎知識ということで、 階層構造 プロトコルの詳細と通信の流れ MACアドレスとIPアドレス ネットワーク機器の種類 VLAN iptables network namespace について解説しました。 リンクは以下です。 sagantaf.hatenablog.com sagantaf.hatenablog.com 上記の項目を理解しておくことで、Dockerのネットワークの仕組みをスムーズに理解できると思います。特にiptablesとnetwork namespaceの理解は必須です。 本記事では、上記の内容を元に、Dockerのネットワークの仕組みを紐解いていきます。 Dockerのネットワークの概要 デフォルト設定 bridgeネットワークの詳細 コンテナ起動時のネットワーク構成 コンテナを起動して

パート2では「開発プロジェクトの工程全体の中におけるモデリング」という視点から、実際のモデリングに必要な要素や具体的な作業の進め方を解説していきます。なぜそのような視点にしたのかは本編で述べていますが、基本的には筆者のこれまでの経験上、実際の開発現場で通用するモデリングのスキルを取得するにあたっての最短の近道だと考えるからです。これまでのモデリングに関する書籍や記事とは一味違った切り口での説明になると思いますが、どうぞ最後までお付き合いください。 "教科書に載っていない"モデリング作法とはこれまでに筆者は、データモデリングに関する数多くの書籍や雑誌／Webの記事を読んできました。それらから得た知識は、確かに実践の中で活かされてきましたが、実際のプロジェクトでDB設計を担当するとなると「記事には載っていない何か」が現場では必要になったのです。世の中にある、多くのモデリングに関する書籍や記事に

はじめに 僕はDeno Land Inc.でDenoを利用したサーバレスエッジホスティングサービスのDeno Deployを開発するチームに所属しています。OSSのほうのDenoのメイン言語はRustで、Deno Deployのバックエンドも同様にRustで書かれています。 今年のアドベントカレンダーで一休さんから以下の記事が公開されましたが、日本でもRustをWebバックエンドの言語として採用する企業がじわじわと増えてきている印象があります。 Deno DeployのバックエンドをRustで開発してきて、RustでWebバックエンドを書くことのメリットやデメリットをいくつか感じたので、この記事で紹介したいと思います。 Deno Deployの構成 まず、ざっくりとDeno Deployのバックエンドの構成を紹介します。 多くのコンポーネントがありますが、ここではどのようにRustを利用し

どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ

DNS リソースレコードを管理していると、「DNS には浸透期間があるため、DNS の設定変更後は24時間〜72時間お待ちいただく必要があります」などと書かれた DNS 事業者の注意書きを見かけることがあります。 ホスティング業者によって「浸透」等が不適切に使われている例 - www.e-ontap.com DNS浸透言ってるところと言っていないところ【レンタルサーバ編】 - ohesotori.hateblo.jp このような記述が蔓延っているために、DNS 利用者の間で「DNS では設定が浸透するまで待たなければならない」という誤解が広まっています。 また、DNS リソースレコードの地理的な伝播状況を可視化するための DNS Propagation Checker なるツールがいくつか存在しています。 https://www.whatsmydns.net/ https://www.ns

という訳で、どーん packagist.org 前に記事を書いたやつです。 daisuki.nichiyoubi.land を書いた後に、先月のPHP勉強会@東京でもお喋りさせてもらったやつでもあります。 (コマンドしか提供しないので、ワークフローファイルを自分で用意する必要がありますが)PRのコメントで起動する使い方が便利じゃない・・・？って思っています。 こんな感じで動くよ 動作例はココにあります。Actionsの設定例もココに。 ブログや勉強会で話をできたことで、「読みやすい簡単なコードにして、面白がってもらおう〜！」という欲は消化されまして、複雑なコードにしました。 クラスが分割されています。(テスト書きにくい部分とかコーディングが面倒くさくなっている部分から逃避していったら、何となく行き着いた〜って感じ) 原型となったプロトタイプ的なスクリプトも同一のレポジトリ上に同梱されており

つくった これのPHP版が欲しいhttps://t.co/vP8dXWbeBc— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2023年8月11日 Google先生が0.43 秒で見つけてくれましたhttps://t.co/TsSGEJqwxs— 今日も誰かのにちようび(おいしい鮭親子丼) (@o0h_) 2023年8月11日 gist.github.com なんで ってことで、試し書き程度にやってみたのでした。 (ちゃんと動くのかな・・・？そんなにしっかり確かめてない。なんとなく行けるのかな、って所まで作ったので晒す) (ちなみに、関数のPHPDocは全部AI Assistantさんがやってくれました) 人に説明や証明する事が面倒くさくてぇ、受け取った側も億劫でぇ・・・みたいなものが世の中にあると、 「説明や証明をしなくて済めばいいのに！あるいは、どっかの誰かが代わりにや

背景・概要 20万行超のコードベースをテストせずにリファクタリングリリースした話 を読んで、面白いなあ、これPHPだとどうなってるんだろう・・・と思って調べてみました。 php-ast というのがあるらしい PHP AST 徹底解説 のような発表があったので、とりあえずそれを使ってみることにした。 インストール $ git clone https://github.com/nikic/php-ast $ cd php-ast $ phpize Configuring for: PHP Api Version: 20170718 Zend Module Api No: 20170718 Zend Extension Api No: 320170718

この記事は FastDOCTOR After Advent Calendar 27日の記事です。 はじめに ファストドクター株式会社でテックリードをしている shirauix と申します。 弊社では、ある Next.js アプリケーションを別会社のパートナーさんに外注することによって初期開発を行いました。ある時点からこのシステムを内製化することになったのですが、それにあたって多くの課題を解決する必要がありました。 この記事では、外注と内製のそれぞれのメリット・デメリットや、内製に切り替える際にどんな苦労があったのかについての赤裸々な事例をご紹介します。 対象となる読者 外注で初期開発したシステムを内製に切り替えてメンテナンスしようとしているエンジニアの方 新しくシステムを開発したいが、外注と内製のどちらを選択すべきか悩んでいる方 外注と内製の違い 外注するか内製するかはあくまで手段の話であ

皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの

クラスター株式会社でSoftware Engineerをしている thara です。 私たちは今年、clusterのシステム分割という重要なプロジェクトを完了しました。この取り組みは、私たちのメタバースプラットフォームの進化と持続可能な成長にとって欠かせないものでした。 本記事では、システム分割の技術的なアプローチとその過程で直面した課題とプロジェクトの結果について説明します。 背景 解決策 システム分離プロジェクトにおける課題 課題を解消するための実施手法 Gatewayによる隔離 dual writeによる段階的移行/dual readによる差分検証 状態スナップショットによる差分検証 諦めの局所化 分離プロジェクトの結果と反省 今後の展望 背景 clusterがリリースされて6年が経過しました。 prtimes.jp 当初はバーチャルイベントプラットフォームとして展開されていましたが

この記事は一休.com Advent Calendar 2023 25日目の記事です。 一休レストランでは、よりスムーズな予約体験の提供を目的とするシステムのリニューアルを進めています。その一環として、2023年10月から、レストラン個別ページの表示から予約までのスマートフォンビューにおいて、バックエンドのサーバをRustで書かれたものに置き換えました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) October 4, 2023 本番運用が始まって3か月近く経ちましたが、これまで安定して継続的な開発と運用ができています。これはRustだからと構えることなく、「ふつう」のバックエンド

はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない

20XX 年、我々人類は進化著しい AI に驚くしかない日々が続いています。ソーシャルメディアに驚きがあふれインプレッションを競う様はまさに大海賊時代、いいねの海賊王に俺はなる、とばかり飛びぬけて耳目を引く超新星 ( スーパールーキー ) が頭角を現しています。 「プロ驚き屋」としばしば称されるルーキーたちは X ( 旧 Twitter ) のタイムラインに現れては情報の正確性を重んじるエンジニアや研究者を戸惑わせます。チームやコミュニティ内の Slack はそうした喧噪から離れたオアシスといえるかもしれません。そんなオアシスにプロ驚き屋を召喚しタイムラインを荒らすのが今回の目的です。次に実際の例を示します。 なかなか模倣できているのではないでしょうか。オアシスは今、ジャングルに変わりました。私たちが生きている世界では正確で吟味された情報だけにアクセスしたいという願いは実現されないので、現