YappliがGoでノーコード基盤刷新、創業時のPHPコードが「技術的負債」になった訳
プログラミング不要、すなわちノーコードでアプリを開発・運用・分析できるプラットフォームが「Yappli」だ。最近はテレビCMの積極的な出稿で一般への認知度を高めている。導入企業は600社を超え、2022年5月時点でのアプリ数は730弱、アプリの総ダウンロード数は同年1月に1億を超えた。 Yappliを提供するヤプリが創業したのは2013年（当時の社名はファストメディア、現社名は2017年から）。創業時のYappliのサービスは、同社の共同創業者である佐野将史氏（現取締役）がプログラミング言語「PHP」を使ってほぼ独力でつくり上げた。 Yappliのシステムは、大きく「コンテンツ管理システム（CMS）」と「アプリ用API（アプリケーション・プログラミング・インターフェース）サーバー」から構成される。ユーザー企業のアプリ運用担当者は、CMSを使ってアプリのデザインや機能を設定し、この情報がデー
README に開発のセットアップ方法を書こう（書いてくれ） - Qiita
READMEに何を書くべきか問題 リポジトリの顔とも言うべきREADMEに何を書くべきかは多くの方が議論されていると思いますが、ここではリポジトリのソースコードを利用して開発を始める時の手順（セットアップ）の記述に関して、自身の体験など踏まえて意見を整理しておきます。 READMEは誰が見るの？ リポジトリの作者や以前からのコミッターはそのリポジトリの内容に精通しているので、正直READMEなんて見なくても問題ないです。問題なのは初めてリポジトリを見に来た人たちです。ネットの大海原の中から奇跡的にこのリポジトリに辿り着いた通行人たち。リポジトリの目的や内容・特徴を簡潔に説明し、彼らに少しでも興味を持ってもらうための手段がREADMEと言えます。ですから、 READMEはリポジトリ初見の目線が大事です。 製作者のメモ書きみたいな暗号文を記載されても困ります。もっとも 数週間もすれば過去の自分
WWDC 2022 基調講演 まとめ （新しいフレームワークの紹介とSessionリンク） - Qiita
※一般公開されているWWDC Keynoteの動画と公開Session/Documentationページだけを使ってこの記事を執筆しました。 「(API)」と表記されている機能は、開発者が自分のアプリで利用できる機能であることを意味します。 iOS 16 フレームワーク WatchOS MacBook MacOS iPadOS iOS 16 通知とライブ活動 (API) 通知は、画面の下部に表示され、非表示にすることができます。 ライブ活動 API は、ユーザーがロック画面で素早く状況を確認するのに役立ちます (音楽、乗車の進行状況、スポーツのスコアなど)。 Qiita記事 ホーム画面のカスタマイズ (API) Apple Watchのホーム画面と同様に、ロック画面の背景、スタイル、フォントを変更することができます。 背景には、シャッフルされた写真を選択することができます。天気や地球のアニ
Unicodeの異体字セレクターを使ったステガノグラフィ：秘密の文字列をテキストにこっそり隠し込む方法 - Qiita
Unicodeの異体字セレクター(variation selectors)を使い、ユニコード文字列内に隠し情報を埋め込む方法です。 異体字セレクターとは 異体字セレクターは、文字の字体を詳細に指定するモディファイアのようなもの 異体字セレクターは16種類のコードポイントがある(FE00~FE0F) 仕組みの概要 隠したい文字列(hidden)を文字単位にバラす (例: js → j, s) 文字ごとに16進数に変換する (例: j → 6A) その16進数をひと桁ずつ異体字セレクターのコードポイントにマッピングする (例: 6→FE06, A → FE0A) 異体字セレクターの配列をひとつの文字列にまとめなおす 最後にそれを埋め込み先の文字列(body)に混ぜ込んで隠す。 よくあるユニコードステガノグラフィーとの違い ゼロ幅文字を使ったステガノグラフィー 次のようなゼロ幅空白文字を用いたス
全員野球からPagerDutyまで。NewsPicksのオンコール体制はどう進化してきたか。 - Uzabase for Engineers
こんにちは！NewsPicksエンジニアの森川です。今回はNewsPicksのオンコール(=障害対応)体制の変遷と試行錯誤をご紹介したいと思います。 オンコール1.0 ~ 全員野球時代 ~ オンコール2.0 ~ 当番制時代 ~ 1. 専門外のアラートに対応できない 2. 対応するエラーの数が多すぎる 3. 勤務時間の自由度が減る 4. slackに気づけない オンコール3.0 ~ PagerDuty時代 ~ 1. アラートを緊急度で仕分け 2. 当番ローテーションの変更 3. PagerDutyの導入 おわりに オンコール1.0 ~ 全員野球時代 ~ NewsPicksにはエンジニア全員が入るslackチャンネルがあり、ここで周知事項の共有や雑談、問い合わせがされています。昔はこれに加え不具合の報告や監視システムからのアラート通知もこのチャンネルに流れるようになっており、アラート通知は気づ
ポストモーテムテンプレート - PagerDuty Incident Response Documentation
これはPagerDutyで利用している標準的なポストモーテムのテンプレートです。 それぞれのセクションでは、あなたがポストモーテムに書くべき情報について説明します。 ガイドライン このページはインシデント発生後5営業日以内に設定されるポストモーテムのミーティングで確認することを目的とします。 最初のステップはインシデント発生の5営業日以内に、共有カレンダーにミーティングを設定することです。 情報が埋まるまでミーティングの設定を待ってはいけませんが、ミーティングまでにページができているようにしてください。 ** ポストモーテムのオーナー:** ここにはあなたの名前が入ります。 ** ミーティングの対象:** インシデント発生後5営業日以内に、「インシデントポストモーテムミーティング」を共有カレンダーにスケジュールします。ここに日付を入力してください ** 通話の記録:** インシデントの通話
週刊Railsウォッチ: Shopifyのlanguage server ruby-lsp、PostgreSQL 15 Beta 1リリースほか（20220607後編）｜TechRacho by BPS株式会社
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Ruby 🔗 Rubyでスクレイピングを書いて中古ギターを買った（Ruby Weeklyより） 元記事: Scraping Buy: Scripting
エンジニアの「生産性」どう測る？ 開発サイクル改善の次の一手に挑むアンドパッドの挑戦 | SELECK [セレック]
エンジニアの「生産性」を、どのように測れば良いのだろうか？ 2014年に創業し、建設・建築現場で使えるクラウド型のプロジェクト管理サービス「ANDPAD」を提供する株式会社アンドパッド。 2020年には合計約60億円の資金調達を行い、2022年4月時点でおよそ600名の従業員を有するなど、急成長を続けている。 同社のアカウント基盤チームでは、エンジニアのパフォーマンスを解析するSaaS「Findy Teams」を活用し、組織の生産性を可視化。チームの課題を特定した上で複数の施策を実施した結果、「平均プルリクエスト クローズ時間」の指標が、120時間から23時間ほどに激減したという。 この取り組みの中心となったテックリードの柴﨑 優季さんは、改善を行うにあたり「指標だけではなくチームの観察からボトルネックを特定する」「敢えて大きな課題から取り組まない」「自分一人がチームを変えるのではなく、チ
![エンジニアの「生産性」どう測る？ 開発サイクル改善の次の一手に挑むアンドパッドの挑戦 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fb26aea0e63f694bb12bb986be86be62f44662bb/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2022%2F06%2F06104511%2F8756cab8425c62d97a74231f915548b9.jpg)
不確実性に立ち向かう一つのTips〜リスク管理に取り組んだ話〜 - BASEプロダクトチームブログ
こんにちはエンジニアリングマネージャーをしております植田です。4月18日にグロースプランの提供が開始されました。今回この開発プロジェクトにて「リスク管理」に取り組んでみたのでそのお話をします。 Index リスク管理に取り組んだ背景 そもそもリスク管理とは 具体的なリスク管理の進め方 リスク管理はどのようなプロジェクトで実行すべきか 実際にどのように取り組んだか 取り組んで良かったことと、今後発展させたいこと リスク管理に取り組んだ背景 まず今回なぜリスク管理に取り組んだかをお話します。BASEでは現在大小様々な開発プロジェクトが同時進行していますが、日に日にその複雑性は増しています。年月を追うごとに積み重なる仕様、日に日に拡大していくリポジトリ（ソースコード群）…と、複雑性・難易度は増す一方です。その中で、開発プロジェクトもいわゆる「不確実性が高い」と言われることが当たり前の状況になって
アクセスログ解析サービスVisionalistで利用していたドメイン（tracer[.]jp）の脅威分析と注意喚起 - NTT Communications Engineers' Blog
はじめに イノベーションセンターの神田です。 みなさんはVisionalistというサービスをご存じでしょうか。 VisionalistはNTTコミュニケーションズのグループ会社であるNTTコム オンライン・マーケティング・ソリューション（以下 NTTコム オンライン）が提供していたアクセスログ解析サービスです。 2020年7月にサービスを終了しましたが、2022年5月にこのサービスで利用していたドメインを第三者が再登録し、セキュリティ上問題があるスクリプトを設置している可能性が確認されました（以下 本件）。 本件について、NTTコム オンラインは広く注意を呼びかけています。 本件に対して、イノベーションセンターでは事象が確認された直後からそのリスクの有無や程度について詳細な調査を実施してきました*1。 本記事は、本件におけるリスクがこれ以上拡大しないようにこれまでに我々が確認した事実とそ
![アクセスログ解析サービスVisionalistで利用していたドメイン（tracer[.]jp）の脅威分析と注意喚起 - NTT Communications Engineers' Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f28058c383a69917b985ef2447a2eb54088c0d3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FN%2FNTTCom%2F20220603%2F20220603204839.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - amoffat/supertag: A tag-based filesystem
GitHub - Shopify/ruby-lsp: An opinionated language server for Ruby
