インボイス制度や電子帳簿保存法の改正を受けて、受取請求書サービスが盛り上がりを見せており、本連載でも過去2回取り上げた。一方で、請求書を発行する側については、インボイス制度に対応するために適格請求書番号の記載を追加などのレイアウト修正はあるが、そこまで大きな変化は見られない。 請求書を発行する、という処理だけでいえば、Web上で探せばExcelやWordの無料フォーマットも見つけることができ、freee会計やMFクラウド会計などに付属する機能でも対応することもできる。請求書発行という機能だけでサービスを継続することは非常に難しく、多くのツールは姿を消していった。 そんな中において未だにユーザー数を増やしているのがboard(ボード)である。単に「請求書を発行する」だけでなく、その前後の業務プロセスをうまく機能に組み込むことでユーザーの支持を得ているのだ。本稿では請求書発行ツールとboard
こんにちは! 引っ越しのために本棚をひっくり返していたら、エンジニアなりたての頃の勉強ノートが出てきました。 今となっては全く役に立たないノートなのに、なんとなく捨てられない とと です。 毎日頭が沸騰するんじゃないかと思うくらい頭をフル回転させて、人生で一番カロリーを使っていたのか、あのときほど減量に成功した日はいまだかつてありません。 (プログライミングダイエットと呼んでいます ※効果には個人差があります) Unitテスト書いてますか?GitHub Copilot使ってますか? さて、わたしは普段、STORES 決済 アプリ/SDK を開発するチームでiOSエンジニアをしています。 この2つのプロジェクトの現在のUnitテストのカバレッジは以下の通りとなっています。 アプリ: 33.15% SDK: 27.98% 結構頑張っている方だと思うのですが、どうでしょうか? STORES 決済
Google、Python環境の「Colaboratory」にAIによる開発支援機能を搭載へ。自然言語からのコード生成、チャットボットによる質疑応答など Googleは今月(2023年5月)に開催したGoogle I/O 2023で、同社として最新の大規模AIモデル「PaLM 2」を発表しており、今回Colaboratoryに搭載されるのも、このPaLM 2に基づいてコードの生成用に作られたモデル「Codey」です。 このCodeyを用いて、Colaboratoryには数カ月以内にコード補完、自然言語によるコード生成、コード支援チャットボットなどの機能が搭載される予定です。 下記は「import data.csv as a dataframe」という自然言語での入力からコードが生成されたところ。
5/10から5/14の5日間、RubyKaigi 2023に参加するために松本市に行ってきました。前回参加したのがRubyKaigi 2019の福岡のときなので、じつに4年ぶりの参加でした。 今回はコミッター/登壇者/LTスピーカーとしての参加になりました。その結果、0日目のDevMeeting含めて3種類のスライドをつくり、3日目の"Ruby Committers and The World"含めて3回登壇するというイベント盛りだくさんなKaigiでした。 いやー、自分のRubyKaigi史上、最高のRubyKaigiでしたね。まさにParserKaigiだったのではないでしょうか。 いろいろ書きたいことはありますが、まずは時系列で振り返っていきましょう。 Day 0 (5/10) - DevMeeting DevMeetingに参加するためDay 0から松本へ向かいました。新宿から特急
はじめに 市民開発者が増えてくると、以下のような問題が発生する可能性があります。 このような問題の解決策として、アプリやフローをカタログ化するというアプローチがございます。 こちら、実際のアプリの画面です。 今回は、こちらのアプリについて、機能、特徴、メリット、良くいただく質問 (FAQ) について説明します。 Power Platform カタログの機能、特徴、メリット 登録されているアプリの再生 登録されているアプリの再生ボタンを押すとアプリが再生できます。個人的に、このアプリを Teams の左メニューに追加しておき、あまり使わないアプリを探して起動する時やお客様向けにデモをする時などには、Teams からこのアプリを開き、個々のアプリを起動しています。 アプリを Teams に追加 Teams のアイコンをクリックすると、Teams にアプリを追加できます。普段 Teams をコミ
はじめに 新卒3年目のらぴおです。入社当初からエンジニアとして広告事業を営むZucksでアドネットワークの開発、運用に携わっています。 Zucksでは、2022年夏頃から円安の影響でサーバ費が上昇しコスト削減の温度感が高まっていました。 そこで、 僕が携わるアドネットワークにおいては、少ない作業量で大きい見直し効果が期待できそうなAWS S3のコスト最適化に取り組む ことになりました。 S3全体で月々のコストが $ 13,000 を超えており、特に広告配信関連のログデータが大部分を占めていました。 今回は、僕が実施したコスト削減調査と実施プロセス、その成果を共有します。 S3のコスト削減は、以下のアプローチで行います。 オブジェクト数を減らす 最適なストレージ階層に移行し保存する これらの取り組みにより、月々のストレージコストを $ 13,000 から $ 5,000 に削減 することがで
こんにちは!フロントエンド開発課のkoki_matsuraです。 この記事では、僕が開発に携わっている製品のE2Eテストに取り入れたページオブジェクトモデル(POM)という実装パターンの概要と取り入れたキッカケ、POMへリファクタリングする簡単な例をご紹介させていただきます。 僕と同じようにE2Eテストに関わっている方、E2Eテストに興味を持っている方などに読んでいただけると幸いです。 目次は下記のようになっています。 POMとは なぜPOMを使い始めたのか POMへのリファクタリング ログイン画面 テスト内容 POM導入前のテストコード ページオブジェクト作成 POM導入後のテストコード 終わりに POMとは Webアプリケーションのテスト自動化において、テストコードとWebページを分離して管理する手法です。 POMを使わない従来のテストコードはWebページと分離しないため、どうしてもD
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上(2023年1月末時点)のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS(Identity as a Service)のOkta Customer Identity Cloud(Powered by Auth0)(以下Auth0という)の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対
LLM、GPT界隈を追いかけていて、GPTの仕組みと限界についての考察(2.1) - conceptualizationという記事を見かけた。これを見たとき、「どういうことか全然理解できない」という気持ちになった。また、その他LLMの解説記事を理解できないことが多く、自分の機械学習知識不足が明確になった。 理解できなかったことは悔しいし、LLMやChatGPTをうまく使いこなすには最低限どのような原理で動いているか理解したいと感じた。そこで一歩目として「ゼロから作るDeep Learning」を完走した。 ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 作者:斎藤 康毅オライリージャパンAmazon 知識なしからはじめたので時間はかかったが、次のように進めていった。 自分もコードを写経しながら読む レポジトリは https://github.co
海外メディアGQは5月22日、『ファイナルファンタジーXVI』のプロデューサーを務める吉田直樹氏とのインタビュー記事を公開。このなかで吉田氏は、“『ファイナルファンタジー』シリーズからナンバリングを撤廃する可能性”について回答し、ファンからの注目を集めている。 『ファイナルファンタジー』シリーズは、1987年にファミコン向けに発売された『ファイナルファンタジー』から続く長寿シリーズだ。ゲームジャンルを異にするスピンオフ作品を含め多数のタイトルがリリースされるなか、メインシリーズのナンバリングとしては今年発売される『ファイナルファンタジーXVI』にて「16」に至る。 今回のインタビューにて吉田氏は、『ファイナルファンタジー』シリーズは各作品それぞれが個性的なキャラクターの物語と設定を有しているため、これまで35年間もシリーズを継続することができたのだろうとコメント。仮に35年続くひとつの物語
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
この記事で書きたいことは、以下のような内容です。 ・成果物やパフォーマンスを公開する時、どうしてもハードルを下げたくて、卑屈になってしまう時があります ・ですが、我々は「成果を誰かに見せる」時卑屈になるべきではありません。少なくともその時その場では、「これは最高の成果物だ」と信じて発表しなくてはいけません ・それは何故かというと、「自分の成果物への信頼」が、実際に受け取る側から見たクオリティにも直接影響する為です ・これは、成果物を作り上げていく過程で努力することや、色んな意見や批判を受けいれてクオリティを上げていくこととは矛盾しません。むしろワンセットの話です ・卑屈になっていると公開自体のハードルが高くなってしまうこともあり、無駄にMPを消費します ・我々には「自分の卑屈さをねじ伏せる覚悟」が必要です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く