Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
Web アプリケーションを書くときは今までずっと 小さい物は web.go 大きい物は net/http というスタンスを何故か貫いて来たんだけど、最近ようやく web.go をやめて goji を使う様になった。 Goji A web microframework for Golang https://goji.io/ 理由としては Sinatra ライクでありながら高度な正規表現マッチも使えるルータ それでいて net/http コンパチ 簡単に実装出来るミドルウェアスタック グレースフルシャットダウン そして何と言っても速い ミドルウェアも一般的な Web アプリケーションを作るには十分な物が既に揃ってます。 それでもやっぱり大きめな物は net/http で書くんだけど、小規模から中規模な物を一気にゴリゴリっと書く場合には goji は便利です。もちろん Windows でも動きま
Vagrant では、一つの BASE BOX イメージから、複数の VMを起動することができるようになってえらくステキです。 勿論、複数のイメージファイルを指定することもできますけれども、BASE BOX は素の状態にしておいて、各サーバは Chef の Role を使って識別して、構成できるようにするのが宗教的理由により優れていると判断しましたので、そのように構成してみようと至ったわけです。 今は、たまたま、ZABBIX2.2の環境を構成しようとしているのですが、ZABBIX の Webフロントエンドと、ZABBIX本体(+DB)を別々のサーバにして構成してみようというところから、この考えに至ったというか、今朝、入門Chef Solo - Infrastructure as Codeを読んでいたら、「Vagrant で、複数のVMを管理できるのか!!( ﾟдﾟ )ｸﾜｯ!! Vagra
![[Vagrant] Vagrant で複数のVM を立ち上げて、お互いに通信できるようにするには [VirtualBox] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3e21ffebfe7a96b365c1ec378ff651df0d2251a8/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMzcyNjMlMkZwcm9maWxlLWltYWdlcyUyRjE1MTQ0NDYzMDA_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9NjZiMDQ0NWY2YTI5MDFjZjA1ZjY1ZDFiYWIzYzNmMGM%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D5416e92f8f52f41915d863924b4abf36%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCVmFncmFudCU1RCUyMFZhZ3JhbnQlMjAlRTMlODElQTclRTglQTQlODclRTYlOTUlQjAlRTMlODElQUVWTSUyMCVFMyU4MiU5MiVFNyVBQiU4QiVFMyU4MSVBMSVFNCVCOCU4QSVFMyU4MSU5MiVFMyU4MSVBNiVFMyU4MCU4MSVFMyU4MSU4QSVFNCVCQSU5MiVFMyU4MSU4NCVFMyU4MSVBQiVFOSU4MCU5QSVFNCVCRiVBMSVFMyU4MSVBNyVFMyU4MSU4RCVFMyU4MiU4QiVFMyU4MiU4OCVFMyU4MSU4NiVFMyU4MSVBQiVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MSVBQiVFMyU4MSVBRiUyMCU1QlZpcnR1YWxCb3glNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz05MjhjYzI4ZjVlM2I2OTRiM2MzZjIwOWQwOGE5MjU0Nw%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBzaG83NjUwJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9ZDBiOTg1MGQ0MzVmY2QxZjM5NTQwYWI3Zjc3ZTBjYTE%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D81443a6f5133debddd508edc63f28532)
起業してアプリを出す。 一言で言ってしまえば簡単なんですけど、最初のそのアプリリリースの時に失敗する人が少なくない気がします。 僕の観測範囲だけでも、独立してアプリを出そうとして開発に失敗、「作り直し→リリース延期」となるケースを定期的に目撃しますので、それなりにそういう失敗をする人はいるんじゃないでしょうか。これが20代の若手が失敗したというならまだ分かるんですが、経営者としてすでに十分な実績のある、僕自身も尊敬するような方がその陥穽に陥ったりしていますので、これはもう能力とか才能の問題でなくて、むしろ「知識」の問題なんじゃないかと思うんですね。 そういう僕も、kiznaというアプリを出そうとして落とし穴にはまってしまい、結局日の目を見なかったという苦い経験をしていますので、こういう経験はちゃんと共有して、無駄な犠牲者が出ないようにすべきだと思うわけです。 というわけで、初めてアプリを出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
