GASを使って運転日報のWEBシステムを作ってみた話
GASでこんな事が出来るよ。という一例として書かせていただきます。 事の成り行き 事の始まりは、ある飲み会の時に自社の営業部門のマネージャ（M）から言われた一言。 M「あのさ。今、うちって社用車を使ったら紙に運転日報を記録して管理してるじゃん？それをやめようと思ってスプレッドシートで管理しようとしたんだけど、毎回スプレッドシートにアクセスして記入するのって億劫だしiPhoneからだと入力しにくくて。。。なんか良い感じに、アプリケーション作ってくれない？」 私「あ、なるほど。ならGsuite(google)だけで完結する、アプリケーション作りますよ。ちょうど明日から出張だったんで、行き帰りの新幹線の中ででも作っときますね。」 という事があり、運転日報をGASで運転日報を作りました。 まずは、完成して現在運用している画面を見てください。 後半で画面の全体と説明を行いたいと思いますが、このような
Twitterの名前を5分毎に東京の天気⛅☂☃と連動させるサーバレスプログラムを書いたら色々知らないことが出てきた話 - Qiita
みんなが使えるようになりました(追記 2018/11/20) 【祝】Twitterの名前をお天気と連動されるアプリを作った時の技術的な紹介【公開した🌥️】 導入 みなさんこんにちは！ 私は将棋プログラムPonanzaの作者、山本一成といいます。Qiita初投稿です。よろしくおねがいします。 いつものようにTwitterをしていた時、ふと思ったんです。 「Twitterの名前の部分が天気のEmojiと連動して変わったら嬉しいな」 つまりこんな感じですね ↓ いつもは、C++など低いレイヤーのプログラムを書くことがメインなので、こういったプログラムを書いたことがあまり経験がないのですが、よしいっちょやってみるかと思ってやってみました。 技術選択 さっそく技術選択の段階です。 こういう類のプログラムは技術の選択がとても大切です（たぶん）。 正しい技術選択をすればとても幸せなのですが、間違えると
AWSの料金を「ざっくり」計算できるサイトを作る - Qiita
AWSの料金、ややこしいですよね。 サービスの選択肢が多く構成が柔軟なおかけで、さまざまな要件をカバーできるのは嬉しいのだけど、そのぶん料金体系がややこしいので、やるせない気持ちになります。 この気持ちはなんだろう、この気持ちはなんだろう、と自問しているうちに春になってしまったので、AWSの料金を「ざっくり」計算できるサイトを作り始めました。 ざっくりAWS 公式ツールの存在 Simple Monthly CalculatorというAWSの料金を計算できる公式のツールがあるのですが、悲しいことに名前ほどシンプルではありません。 正確な料金を算出するために入力項目が多いのは仕方がないとは思うのですが、サイトを開いたときの威圧感がすごいので、もう少しさっぱりできないかという気持ちがありました。 なので、公式ツールの敷居が高いと感じる自分のような人向けに、料金を「ざっくり」計算できるサイトを作り
JavaScriptで制御できるWebベースの万能マップエディタ「Mapbox Studio」を使ってみた！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回は、自分好みのマップをブラウザ上でカスタマイズしたり、JavaScriptから自在に制御可能な地図サービスのご紹介です！ データを取り込んでマッピングしたり、プラグインによる拡張も可能で自分のWebアプリやサービスなどにも簡単に組み込めるスグレモノです！ 【 Mapbox Studio 】 ■「Mapbox Studio」の使い方 それでは、まず最初に「Mapbox Studio」の基本的な使い方から見ていきましょう！ 初めての人は無料のユーザー登録が必要なので、サイトのトップページにあるボタンをクリックします。 好きなユーザー名・メルアド・パスワードだけで、簡単に登録ができます！ 登録後は、Webページにマップを表示させる簡単なチュートリアルが始まるので、試しにやってみましょう！ 表示された画面にある「JS」の項目をクリック！ 左側の「C
色々なプログラミング言語で JSON をパースするためのイカしたサービス quicktype - かずきのBlog@hatena
今日、マイクロソフト本社から来た David さんとお昼ご飯をしたときに教えてもらえた彼のプロダクトが凄かったので紹介したいと思います。 quicktype.io quicktype JSON をペーストするとシリアライズ・デシリアライズするためのコードを出力してくれるサービスです。 例えば、以下のような JSON があるとします。 { "name": "Kazuki Ota", "age": 36, "pets": [ { "name": "hoge" }, { "name": "foo" } ] } ページに張り付けるとこういうコードが生成されます。 // To parse this JSON data, add NuGet 'Newtonsoft.Json' then do: // // using Sample.Models; // // var data = Person.Fro
【Rails】WEB APIを長く運用するための仕組み化 - ZOZO TECH BLOG
こんにちは、バックエンドエンジニアのじょーです。大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すA
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
