“全員分の QR コードで動作確認して正常系では動くことを確認した“やっぱり異常系の動作確認って重要なんだな
年齢知らんが現場見たりヒアリングせずにどうでも良いとここだわった典型的な失敗で良い経験だね。
自己満足要素の強い仕掛けは、ゲストに迷惑をかけやすいな(飛行機チケットに模した招待券とかも)。ゲストに負担をかけずに楽しんでもらい、システムをいれるなら通常の受付以上のメリットがなきゃやる必要ない。
どうでも良いのですがQRコードにはクワイエットゾーンが必要ですよ
これだからAIは。
"参列者は QR コードをかざすだけで受付が完了" 「当日QRコード持参」という余計な手間を参列者に押付けてるのに、ほら楽だろうみたいな考え方はどうかなー。
お遊びアプリとはいえカネの出納を扱うシステムで機能要件すらギリギリ（修正ができないとか……）で非機能要件（ユーザビリティ）は皆無、並列処理は想定外かぁ…最後の採用に応募したくなる人はいるのかな
『結婚式はなんぼあってもいいですからね。』結婚式の最中にだけは絶対に口に出さないようにお願いします
現場での運用の重要性がよく分かったのだし、本人の結婚式なんだからやりたいことやるのはイイんじゃないかな。手伝ってくれた人はそりゃ大変だったろうが、式自体本人たちのためのイベントなんだしな。
まぁ個人の範囲だからどうも言わんけど、QRとアプリでその時限りの利用なんて利用側の負担と不安やなぁ。あとゲストに書いてもらう芳名帳も大切な思い出になると思ってるのでデジタルにするの勿体無いな（昭和脳
運用テストですって言っとけばよかったのに
「次が本番！」
何を解決したくて、どうして自作したのか、なぜこれを会社ブログで公開するのか何もかもわからない内容だった。受付の負担を減らしたいなら全部スマホ上で完結でよかっただろうに。結婚はおめでとうございます。
PDCA！PDCA！次は赤子夜泣きシステム!
面白い
何を解決したかったんだろう。名前を書いてもらってる間に探すので特に問題なかったのに／同時アクセスはないとあるけど、新郎側新婦側で受付を分けなかったわけ？5人もいるのに
学生の文化祭エピソードだったらいい経験積んでるなぁってなったけど、エムスリーのテックブログなんかい。ここのエンジニア集団ってもっとハイレベルだと思ってたのだけど
この要件で JSON 読み書きという時点で以降の話が入ってこなかった。
失敗は経験になる。次に結婚するときはもっと上手く出来ると思う。
あと3回くらい結婚式すればやや安定運用できるものにできると思いますよ。
「アプリには一度ご祝儀の受領処理を行うと取り消せないという致命的なバグが混入していました」 今どき、ユーザー側でもこんなバグチェック位はするだろうに、テック系企業の従業員がこれって、ちょっとどうなん？
JSONは甘え、fwriteでバイナリを書くのだ。とかそうじゃなくてファイルだと基本的に直列にしか処理できんよね。DBって偉大だ。
https://chatgpt.com/s/t_6857b2b6ccf88191ba9eb2f4e1c8bd5a この失敗から学べるよう、代わりに考えてあげたゾ コンサル料ちょうだい
QRコードを回収すればよかったのでは
いろんな教訓がつまってて、新人研修で真に顧客が必要だったシステムをつくる課題にうってつけ。"結婚式はなんぼあってもいいですからね" 今回はごめんね！次に式をあげるときはもっといいやつを持ってきますよ！！
このQRコードを受付に使うとは思わんやろ…
バグ？仕様通りの検討漏れでは
自分たちの結婚式なら赤の他人は参加してないはず。トラブったとしても迷惑がかかるのは知り合いだけだしどうでもいいんじゃね。何で他人の結婚式の成否が気になるのかさっぱり分からない。
奥さんが良く許してくれたな、と思いながら本文読んだら夫婦で一緒にシステム作ってて安心した。片方が独走したパターンだと後々まで祟りかねないけど、これは2人で失敗してるのでむしろ仲が深まりそう
CTOとして採用してもらえるなら・・・ｗ
“凝り性の妻が本物の航空券のように入場券を作り込んだところ、入場券を LINE で受け取った人の中から「私たちは新幹線で行くので航空券は不要ですよ」と言う人が出てきました。”
これでプロの仕事なの？不安が…
フォローすると、機械学習エンジニアとあるので、アプリの設計経験はあんまりないんじゃないかなあ。ただ、結構初歩的な失敗談の後に 「We are hiring!」 はちょっと笑っちゃった笑
とにかくご結婚おめでとうございます！！何事も挑戦は大事だ
人間系のイレギュラーが入り込むタスクだ。/ 結婚式が和気藹々と完了し「こんな楽しい結婚式だったら何度やってもいいね」って言ってた友人は2, 3年で離婚したので、望まないのであればほどほどに気をつけてほしい…w
AI、機械学習チームなんだから業務アプリの要件定義なんてやったことないだろ。逆もまた然り。餅は餅屋
さすがにこれは設計段階で気付くべきでは。
結婚式のアプリなら、受付の他にも配席や式次第とかの機能もつけて総合アプリにした方が楽だな
IT界隈だと自分の結婚式で自作アプリを披露する人、結構いるよね。手芸好きな人が、手作りの品を配ったりするのと同じノリなんだと思ってる
カッコ悪くてもいいから「本状で受付を行いますのでお手数ですがお持ちください」と招待状にベタ書きしておくべきでしたね。あとは持ってこないことを想定してQRコードのコピーなり一覧なりも受付に置いておくと。
バグはしょうがない！次の結婚式で再チャレンジだ！
バグじゃないだろ。アプリ設計能力が皆無なだけ。
圧倒的な要件定義不足 こんな会社には絶対仕事出したくないよ
紙でやれ以外の感想がない。受付でコードスキャンするのも雰囲気にそぐわない感。『結局会場が用意した紙の参列者管理表が single source of truth になり』
他人だしどうこう言う筋合いはないけど、ちょっと痛いと思う
SaaS全盛やぞありものでなんとかしろ．ご祝儀はPaypayで集金しろ / 次はうまくやろうねはブラックジョークすぎるやろ草
結婚式はこういうのも付き合わないといけないのか。2次会でネタにされてないことを祈る。
『成功と失敗』ではなく『成功と学習』。この経験は新郎の今後の仕事に絶対に役に立ちます。彼の成長とお二人の幸せを願って挨拶の言葉と変えさせていただきます。
祝儀の確認したいならユーザーに自由に翳させるのはNGだろう。取り消せないのも含めバグじゃなく設計の問題では。紙でやりたくないなら、選挙の受付システムを参考にすればよかった。まあエクセルで良さそうだけど
業務アプリ開発者でもユーザーのことを一切考えずに実務と乖離する場合があるので良いですよ👍️（良くない）
おめでとうございました(笑)。
何から何まで技術力のない人だな。これを会社のテックブログでやるのか...。
セルフレジで2回スキャンするとどうなるか試してみたくなる精神があればこうならなかったかもしれない
奥さん作の航空券のような入場券とか自分はこういうノリは微笑ましくて好きですよ。末永くお幸せに
めちゃくちゃ良い失敗例、聴衆受けするライトニングトークみたいな内容。とはいえロープレすらしないで作るとは普段から現場軽視する人なんだなぁという気持ちも出る。そしてご結婚おめでとうございます。
タイトル読むだけで冷や汗が出る
重要な場面で自己満足のためのアプリを導入するとか...。 しかも要件もテストも酷い。仕事とプライベートは別物といえど... m3ってこんなレベルなの...？ 企業名出すとこにもびっくり
入場券は流石に説明無しだと何なのかわからなすぎる
🎉おめ🎉自分達の結婚式で何しようと勝手でしょう。参列した人が苦情を言うならともかく。会社のテックブログで書く内容なのか…というのはまぁわかるけど、それも会社側が判断すること。
技術力うんぬんと言うよりは現場系案件の慣れ不慣れかも
金銭が絡むシステムをいきなり実戦投入するな(真顔)
うーん
システムを作り上げる時に色んなことを想定するけど、それが現実に則してないことはよくありますな。 一人で作り上げず、予行演習とかやってフィードバックもらっとけばよかったかもねぇ。
参列の際は同封のチップを右手の親人人差し指の間に移植してご来場下さい。
入場券の作り込みみたいなの、凝り性だからとか関係なくてつらいな
ちょっと真面目に書きすぎでは？もっとやらかしたわ〜！ってテンションで書いた方が面白いのに。せっかくのネタなのに。クソ真面目なはてなーがレビューしに来るつまらん形になってるよ。
昔やらかした失敗設計を思い出す。お幸せに
二人で決めたことならまあいいんじゃないかな
当方フリーランス、こういう数時間しか稼働しない使い捨てシステムの制作運用を業務にしてるけど（主にイベント）、「できませんでした」は許されない上に、スタート30分前に想定してない仕様が加わるとかもザラ。
結婚式アプリ、バグったの！？ボクならもっと完璧に作るにゃ！…って、猫の手も借りたいほど大変だったんだにゃ？
経験者として語るなら自分がフォローできないとこに自作システム使うのは止めたほうがいい。主役の失敗は新郎新婦だけで受け止めれるけど、そうでないと受付お願いした人に迷惑がかかる。
「～散らかす」って表現はいつ頃かなんだろう。「当たり散らす」から変化した感じなのかな。昔お笑い芸人が「ハゲ散らかす」みたいな表現を使ってた記憶だけど、そこからなのかな。
自分の結婚式ならいいんじゃないかな。作ってる最中も楽しかっただろうし、失敗しても誰も怒らないよ、だって新郎新婦の初めての共同作業なんだからね。
トップのコメントが面白かった
まあ笑い話で済むような問題だったからいいんじゃないかな。次回もうちょっとちゃんとやればいい。
ケーキ入刀より先に行ってた共同作業が失敗しとるやん・・・、計機導入失敗
いやーこういう失敗小さい本当に財産になると思う。羨ましいくらいだよ。
顧客が本当に必要だったもの、の画像が頭に浮かんだ
ユースケースの想定って重要だよね。
これ上手く動いていたとしてどの労力がどれくらい減らせる見込みなの？受付の人数減らすのが目的？１人で受付させられる人かわいそう……友人の結婚式で受付担当したこととかないんか……？
地獄・・・。
本番相当の運用テストは超大事ですね。結婚も開発も本番リリースまでよりも移行後の運用フェーズがとても大事なのです。（結婚では本番前に負荷テストできない（やってませんか？））
結婚式などの受付の経験があって、要件定義できて、例外を洗い出せて処理をどこまで実装するか判断できて。そもそも結婚式などの受付の経験があるかないかが大きくて受付の経験があればあるほど実装手法は紙に。
目が笑ってない受付してくれた人は死ぬほど根に持ってるから気をつけような
一回こっきりのことをわざわざシステム化する意味をまず考えた方がいい。自己満足でやりたかったら他人を巻き込まない所でやるべき。現場云々の前に独りよがりが過ぎる。絶対に仕事を依頼したくない
会社の先輩の結婚式の受付やったことある。紙で受付とご祝儀受取はそんなに大変じゃなかった。お車代渡し損ねたとき探すのがちょっと大変だった。／真の要件は夫婦で共作して思い出作ることと思うので、問題なし
率直に言って、こんな話を技術ブログに書く会社には入りたくないなあ。これ現場運用の話じゃなくてソフトウェアの設計の基礎がなってないって話だからね。この人の結婚式がどうなったかはともかく。
ツッコミはあるけど、初歩のアプリってこんな感じ。練習とかテストとかしなかったのかとは思うけど、まあプライベートならなんぼ失敗してもネタになるね
自分の結婚式での失敗談なのでお好きにとは思うけど、会社のテックブログに書く話としてはあまりにもお粗末で目的が謎
ファイル形式としてもSQLiteで良さげな。GUIツール使えばJSON直編集より手修正楽だし。既に突っ込まれてるけど "一度ご祝儀の受領処理を行うと取り消せないという致命的なバグ" は仕様の問題でアプリのバグではない
個人的に、そういうのはFileMakerだったら上手くいった気がする。QRコードで参加者のID認識可能な上、データ編集もその場でJSONよりも遥かに楽に(Excel同様に)行えるので。開発コストも限りなく低い
“最悪 json を直接編集すればいいですよ”そんな事できるわけないだろw中途半端な知識だけで経験ほぼゼロだなこれは。単純な設計ができてない。全員スマホ持ってるんだからPCなんかいらないだろ。頭を使え。
AI・機械学習チームの方だということらしいけど、サービスの機能開発とかは未経験なんだろうか？ってなクオリティだなこりゃ
「ウェディング・ハイ」かな。→頼りない人…
離婚してもう一度やりおなせｗ
凝り性か何か知らないけどみてわからん入場券は意味があるのか……
自己顕示欲どんだけだよ……招待客をテスターと勘違いしてて最悪
「次に結婚するときは」↓悪意としか思えない。／「QRコードをご持参ください」の注意書きは必要だろうね。
“新郎の自己満足アプリは現場に混乱だけをもたらしてその役目を終えました”
カラム数少なくてせいぜい100とか200レコードくらいだと紙の方が便利だなと思った。でも面白い試み。リリース前のテストは入念にという。
結婚式のアクティビティは2人の好きなことすればいいと思うけど、会社の広報活動として掲載するという判断がホラー過ぎない？ 方向性はSNS炎上の類…… 技術者無邪気無罪ってことなら叩かれるのも致し方ない。
自作結婚式受付アプリが当日バグり散らかして現場運用の大切さを噛み締めた話 - エムスリーテックブログ
“全員分の QR コードで動作確認して正常系では動くことを確認した“やっぱり異常系の動作確認って重要なんだな
年齢知らんが現場見たりヒアリングせずにどうでも良いとここだわった典型的な失敗で良い経験だね。
自己満足要素の強い仕掛けは、ゲストに迷惑をかけやすいな(飛行機チケットに模した招待券とかも)。ゲストに負担をかけずに楽しんでもらい、システムをいれるなら通常の受付以上のメリットがなきゃやる必要ない。
どうでも良いのですがQRコードにはクワイエットゾーンが必要ですよ
これだからAIは。
"参列者は QR コードをかざすだけで受付が完了" 「当日QRコード持参」という余計な手間を参列者に押付けてるのに、ほら楽だろうみたいな考え方はどうかなー。
お遊びアプリとはいえカネの出納を扱うシステムで機能要件すらギリギリ（修正ができないとか……）で非機能要件（ユーザビリティ）は皆無、並列処理は想定外かぁ…最後の採用に応募したくなる人はいるのかな
『結婚式はなんぼあってもいいですからね。』結婚式の最中にだけは絶対に口に出さないようにお願いします
現場での運用の重要性がよく分かったのだし、本人の結婚式なんだからやりたいことやるのはイイんじゃないかな。手伝ってくれた人はそりゃ大変だったろうが、式自体本人たちのためのイベントなんだしな。
まぁ個人の範囲だからどうも言わんけど、QRとアプリでその時限りの利用なんて利用側の負担と不安やなぁ。あとゲストに書いてもらう芳名帳も大切な思い出になると思ってるのでデジタルにするの勿体無いな（昭和脳
運用テストですって言っとけばよかったのに
「次が本番！」
何を解決したくて、どうして自作したのか、なぜこれを会社ブログで公開するのか何もかもわからない内容だった。受付の負担を減らしたいなら全部スマホ上で完結でよかっただろうに。結婚はおめでとうございます。
PDCA！PDCA！次は赤子夜泣きシステム!
面白い
何を解決したかったんだろう。名前を書いてもらってる間に探すので特に問題なかったのに／同時アクセスはないとあるけど、新郎側新婦側で受付を分けなかったわけ？5人もいるのに
学生の文化祭エピソードだったらいい経験積んでるなぁってなったけど、エムスリーのテックブログなんかい。ここのエンジニア集団ってもっとハイレベルだと思ってたのだけど
この要件で JSON 読み書きという時点で以降の話が入ってこなかった。
失敗は経験になる。次に結婚するときはもっと上手く出来ると思う。
あと3回くらい結婚式すればやや安定運用できるものにできると思いますよ。
「アプリには一度ご祝儀の受領処理を行うと取り消せないという致命的なバグが混入していました」 今どき、ユーザー側でもこんなバグチェック位はするだろうに、テック系企業の従業員がこれって、ちょっとどうなん？
JSONは甘え、fwriteでバイナリを書くのだ。とかそうじゃなくてファイルだと基本的に直列にしか処理できんよね。DBって偉大だ。
https://chatgpt.com/s/t_6857b2b6ccf88191ba9eb2f4e1c8bd5a この失敗から学べるよう、代わりに考えてあげたゾ コンサル料ちょうだい
QRコードを回収すればよかったのでは
いろんな教訓がつまってて、新人研修で真に顧客が必要だったシステムをつくる課題にうってつけ。"結婚式はなんぼあってもいいですからね" 今回はごめんね！次に式をあげるときはもっといいやつを持ってきますよ！！
このQRコードを受付に使うとは思わんやろ…
バグ？仕様通りの検討漏れでは
自分たちの結婚式なら赤の他人は参加してないはず。トラブったとしても迷惑がかかるのは知り合いだけだしどうでもいいんじゃね。何で他人の結婚式の成否が気になるのかさっぱり分からない。
奥さんが良く許してくれたな、と思いながら本文読んだら夫婦で一緒にシステム作ってて安心した。片方が独走したパターンだと後々まで祟りかねないけど、これは2人で失敗してるのでむしろ仲が深まりそう
CTOとして採用してもらえるなら・・・ｗ
“凝り性の妻が本物の航空券のように入場券を作り込んだところ、入場券を LINE で受け取った人の中から「私たちは新幹線で行くので航空券は不要ですよ」と言う人が出てきました。”
これでプロの仕事なの？不安が…
フォローすると、機械学習エンジニアとあるので、アプリの設計経験はあんまりないんじゃないかなあ。ただ、結構初歩的な失敗談の後に 「We are hiring!」 はちょっと笑っちゃった笑
とにかくご結婚おめでとうございます！！何事も挑戦は大事だ
人間系のイレギュラーが入り込むタスクだ。/ 結婚式が和気藹々と完了し「こんな楽しい結婚式だったら何度やってもいいね」って言ってた友人は2, 3年で離婚したので、望まないのであればほどほどに気をつけてほしい…w
AI、機械学習チームなんだから業務アプリの要件定義なんてやったことないだろ。逆もまた然り。餅は餅屋
さすがにこれは設計段階で気付くべきでは。
結婚式のアプリなら、受付の他にも配席や式次第とかの機能もつけて総合アプリにした方が楽だな
IT界隈だと自分の結婚式で自作アプリを披露する人、結構いるよね。手芸好きな人が、手作りの品を配ったりするのと同じノリなんだと思ってる
カッコ悪くてもいいから「本状で受付を行いますのでお手数ですがお持ちください」と招待状にベタ書きしておくべきでしたね。あとは持ってこないことを想定してQRコードのコピーなり一覧なりも受付に置いておくと。
バグはしょうがない！次の結婚式で再チャレンジだ！
バグじゃないだろ。アプリ設計能力が皆無なだけ。
圧倒的な要件定義不足 こんな会社には絶対仕事出したくないよ
紙でやれ以外の感想がない。受付でコードスキャンするのも雰囲気にそぐわない感。『結局会場が用意した紙の参列者管理表が single source of truth になり』
他人だしどうこう言う筋合いはないけど、ちょっと痛いと思う
SaaS全盛やぞありものでなんとかしろ．ご祝儀はPaypayで集金しろ / 次はうまくやろうねはブラックジョークすぎるやろ草
結婚式はこういうのも付き合わないといけないのか。2次会でネタにされてないことを祈る。
『成功と失敗』ではなく『成功と学習』。この経験は新郎の今後の仕事に絶対に役に立ちます。彼の成長とお二人の幸せを願って挨拶の言葉と変えさせていただきます。
祝儀の確認したいならユーザーに自由に翳させるのはNGだろう。取り消せないのも含めバグじゃなく設計の問題では。紙でやりたくないなら、選挙の受付システムを参考にすればよかった。まあエクセルで良さそうだけど
業務アプリ開発者でもユーザーのことを一切考えずに実務と乖離する場合があるので良いですよ👍️（良くない）
おめでとうございました(笑)。
何から何まで技術力のない人だな。これを会社のテックブログでやるのか...。
セルフレジで2回スキャンするとどうなるか試してみたくなる精神があればこうならなかったかもしれない
奥さん作の航空券のような入場券とか自分はこういうノリは微笑ましくて好きですよ。末永くお幸せに
めちゃくちゃ良い失敗例、聴衆受けするライトニングトークみたいな内容。とはいえロープレすらしないで作るとは普段から現場軽視する人なんだなぁという気持ちも出る。そしてご結婚おめでとうございます。
タイトル読むだけで冷や汗が出る
重要な場面で自己満足のためのアプリを導入するとか...。 しかも要件もテストも酷い。仕事とプライベートは別物といえど... m3ってこんなレベルなの...？ 企業名出すとこにもびっくり
入場券は流石に説明無しだと何なのかわからなすぎる
🎉おめ🎉自分達の結婚式で何しようと勝手でしょう。参列した人が苦情を言うならともかく。会社のテックブログで書く内容なのか…というのはまぁわかるけど、それも会社側が判断すること。
技術力うんぬんと言うよりは現場系案件の慣れ不慣れかも
金銭が絡むシステムをいきなり実戦投入するな(真顔)
うーん
システムを作り上げる時に色んなことを想定するけど、それが現実に則してないことはよくありますな。 一人で作り上げず、予行演習とかやってフィードバックもらっとけばよかったかもねぇ。
参列の際は同封のチップを右手の親人人差し指の間に移植してご来場下さい。
入場券の作り込みみたいなの、凝り性だからとか関係なくてつらいな
ちょっと真面目に書きすぎでは？もっとやらかしたわ〜！ってテンションで書いた方が面白いのに。せっかくのネタなのに。クソ真面目なはてなーがレビューしに来るつまらん形になってるよ。
昔やらかした失敗設計を思い出す。お幸せに
二人で決めたことならまあいいんじゃないかな
当方フリーランス、こういう数時間しか稼働しない使い捨てシステムの制作運用を業務にしてるけど（主にイベント）、「できませんでした」は許されない上に、スタート30分前に想定してない仕様が加わるとかもザラ。
結婚式アプリ、バグったの！？ボクならもっと完璧に作るにゃ！…って、猫の手も借りたいほど大変だったんだにゃ？
経験者として語るなら自分がフォローできないとこに自作システム使うのは止めたほうがいい。主役の失敗は新郎新婦だけで受け止めれるけど、そうでないと受付お願いした人に迷惑がかかる。
「～散らかす」って表現はいつ頃かなんだろう。「当たり散らす」から変化した感じなのかな。昔お笑い芸人が「ハゲ散らかす」みたいな表現を使ってた記憶だけど、そこからなのかな。
自分の結婚式ならいいんじゃないかな。作ってる最中も楽しかっただろうし、失敗しても誰も怒らないよ、だって新郎新婦の初めての共同作業なんだからね。
トップのコメントが面白かった
まあ笑い話で済むような問題だったからいいんじゃないかな。次回もうちょっとちゃんとやればいい。
ケーキ入刀より先に行ってた共同作業が失敗しとるやん・・・、計機導入失敗
いやーこういう失敗小さい本当に財産になると思う。羨ましいくらいだよ。
顧客が本当に必要だったもの、の画像が頭に浮かんだ
ユースケースの想定って重要だよね。
これ上手く動いていたとしてどの労力がどれくらい減らせる見込みなの？受付の人数減らすのが目的？１人で受付させられる人かわいそう……友人の結婚式で受付担当したこととかないんか……？
地獄・・・。
本番相当の運用テストは超大事ですね。結婚も開発も本番リリースまでよりも移行後の運用フェーズがとても大事なのです。（結婚では本番前に負荷テストできない（やってませんか？））
結婚式などの受付の経験があって、要件定義できて、例外を洗い出せて処理をどこまで実装するか判断できて。そもそも結婚式などの受付の経験があるかないかが大きくて受付の経験があればあるほど実装手法は紙に。
目が笑ってない受付してくれた人は死ぬほど根に持ってるから気をつけような
一回こっきりのことをわざわざシステム化する意味をまず考えた方がいい。自己満足でやりたかったら他人を巻き込まない所でやるべき。現場云々の前に独りよがりが過ぎる。絶対に仕事を依頼したくない
会社の先輩の結婚式の受付やったことある。紙で受付とご祝儀受取はそんなに大変じゃなかった。お車代渡し損ねたとき探すのがちょっと大変だった。／真の要件は夫婦で共作して思い出作ることと思うので、問題なし
率直に言って、こんな話を技術ブログに書く会社には入りたくないなあ。これ現場運用の話じゃなくてソフトウェアの設計の基礎がなってないって話だからね。この人の結婚式がどうなったかはともかく。
ツッコミはあるけど、初歩のアプリってこんな感じ。練習とかテストとかしなかったのかとは思うけど、まあプライベートならなんぼ失敗してもネタになるね
自分の結婚式での失敗談なのでお好きにとは思うけど、会社のテックブログに書く話としてはあまりにもお粗末で目的が謎
ファイル形式としてもSQLiteで良さげな。GUIツール使えばJSON直編集より手修正楽だし。既に突っ込まれてるけど "一度ご祝儀の受領処理を行うと取り消せないという致命的なバグ" は仕様の問題でアプリのバグではない
個人的に、そういうのはFileMakerだったら上手くいった気がする。QRコードで参加者のID認識可能な上、データ編集もその場でJSONよりも遥かに楽に(Excel同様に)行えるので。開発コストも限りなく低い
“最悪 json を直接編集すればいいですよ”そんな事できるわけないだろw中途半端な知識だけで経験ほぼゼロだなこれは。単純な設計ができてない。全員スマホ持ってるんだからPCなんかいらないだろ。頭を使え。
AI・機械学習チームの方だということらしいけど、サービスの機能開発とかは未経験なんだろうか？ってなクオリティだなこりゃ
「ウェディング・ハイ」かな。→頼りない人…
離婚してもう一度やりおなせｗ
凝り性か何か知らないけどみてわからん入場券は意味があるのか……
自己顕示欲どんだけだよ……招待客をテスターと勘違いしてて最悪
「次に結婚するときは」↓悪意としか思えない。／「QRコードをご持参ください」の注意書きは必要だろうね。
“新郎の自己満足アプリは現場に混乱だけをもたらしてその役目を終えました”
カラム数少なくてせいぜい100とか200レコードくらいだと紙の方が便利だなと思った。でも面白い試み。リリース前のテストは入念にという。
結婚式のアクティビティは2人の好きなことすればいいと思うけど、会社の広報活動として掲載するという判断がホラー過ぎない？ 方向性はSNS炎上の類…… 技術者無邪気無罪ってことなら叩かれるのも致し方ない。