note.com 僕の間違いじゃなければ、時々はてなのブログでコメントを頂いた方のように思う。Python関係で。大変お世話になりました！ 法人の設立にあたっての事務処理と、会社運営のお気持ち編を、自分の体験からまとめてみます。2016年6月にノリ（そうだ独立しよう）だけで起業して7年ほどひとり。今は2人体制になった。 会社を大きくする方法はなんもわからんので、そういう内容を期待される方はすいません！沿わないと思う！ 1. 決算処理は専門家に任せたほうが良い 自分は前職の会計事務所でお世話になったため、起業当初から会計事務所を利用させてもらっている。年間30万弱。決算処理込み。 6月1日に創業したけど、タイミング的に6月になっただけで、深い意味はなかった。会計事務所的に3末はGW進行と重なるので避けたほうがいいかも。 決算処理は確認しないといけない事項が多すぎて、素人がいくら確認しても漏れ

TOPフォーカスCSS嫌いがあえてフレームワークまでつくった理由。　NES.css開発者流、「嫌い」を「好き」に変える勉強術【フォーカス】 CSS嫌いがあえてフレームワークまでつくった理由。　NES.css開発者流、「嫌い」を「好き」に変える勉強術【フォーカス】 2024年4月24日 「NES.css」開発者 ダーシノ SIerでの業務アプリ開発や職業訓練校でのプログラミング講師を経て2015年にさくらインターネット株式会社にフロントエンドエンジニアとしてジョイン。2018年にファミコン風CSSフレームワーク「NES.css」を開発、公開する。人生の目標に「笑って死ぬ」を掲げている。柔道初段。 X ブログ GitHub ファミコン風のデザインのWebページをすぐにつくれる、オープンソースのCSSフレームワーク「NES.css」。フロントエンドエンジニアのダーシノさんが2018年にGitHu

はじめに 2021年11月に、熊本県内バス5社のリアルタイムバス情報が、GTFS Realtime形式のオープンデータとして公開されました。本記事では、GTFSの概要、熊本のデータ入手方法、利用例、開発情報などを紹介します。 1. どんなデータ？ GTFSって何？ GTFS(General Transit Feed Specification)とは、バスや鉄道などの公共交通に関する世界的なデファクトスタンダードなファイル形式で、Google Maps等の経路検索サービスで主に使われています。 日本においても、2017年に国土交通省がバス情報の標準形式として採用してから普及が始まっています。2021年11月12日現在、440の交通事業者・自治体がオープンデータを公開しており、そのうち遅延等のリアルタイム情報も48社から配信されています。 熊本のバスロケーションシステム 熊本県内では5社・約8

こんにちは。プロダクト開発部のサーバサイドエンジニアの荒川です。普段はSansanのスマホアプリのAPIの開発をしています。 今回扱うテーマは皆さん大好きキャッシュ（Cache） です。 Webアプリケーションを開発するエンジニアである以上、キャッシュの存在からは逃れられないでしょう。 例えばパフォーマンスを向上させる手段として、キャッシュを仕込むことは往々にしてあるかと思います。 キャッシュを使えばパフォーマンスが向上しそう、というイメージも強いため安易に選択する戦略になりがちですが、正しく扱うことは本質的に難しいです。 しかしキャッシュを上手に使えば、ユーザ体験を圧倒的に向上させることができます。 そんな諸刃の剣キャッシュ💰について考慮するべきこと、その戦略を改めてまとめてみました。 今回の対象 今回の対象は、アプリケーションレベルでのキャッシュ戦略を取り扱います。 いわゆるキャッシ

このエントリーはあまりにも辛い思いをしたので、ちょっと口調が粗めとなっております。あらかじめご了承ください。 前説俺はsugitaniという。 色んなシステムを作ってきた開発者だ。ニコ生とかを(実装したという意味で)作った人間だ。 不器用が祟って職を変えことになった。幸いに様々なオファーを戴いた。でも申し訳ないが、やれるけどやりたいと思える仕事はなかった、どうしても心が躍らなかった、俺はCtoCがやりたいのだ。 幸いに、副業先から、それであれば稼働日を増やしてはどうかという提案を戴いた。渡りに船だ。それがあれば、その収入があれば、俺は俺の作りたいシステムを作れる。やるしかない、そうしないと自分を説得できない。 そうして会社を作った。10月末の話しだ。 それから法人（株式会社）の設立は大変だった。大変だったが、それはいい。 12月から自分の会社から自分に給料=役員報酬を払う。給料を払うなら社

この記事を読んだ方から有益な情報をたくさんいただいたので追記している。 特定創業支援等事業の認定 法人設立ワンストップサービス gBizID 自分でやっていないものについては各項目で明記している。 なぜ作ったのか？ 自分の興味があった教育分野において、実際にやってみて自ら経験を積み、社会に役立つようなことがやりたいと思ったため。 あと、長くサラリーマンをやって、矛盾している組織が許せない性分だとわかったので、じゃあ自分で組織を作ってみようという単純な発想による。できるだけ矛盾していない組織を作ろうと目指しているが、やらずに文句だけ言うのはフェアでない、という意味合いもある。 フローチャート やることが多く、時系列がわかりづらかったのでフローチャートを書いてみた。 週一で動いた場合、 3 ヶ月ほどかかる。また、灰色の枠は実施していない。 経費について 登記前にかかった費用はすべて創立費、登記

日記です。 タイトルの通り10年勤めたfreee株式会社を退職して、自分で会社を作ってやっていくことにした。 freee最終出社でした、10年間ありがとうございました！(ビルを見上げる写真撮り忘れた) 次回作にご期待ください！ — yo_waka (@yo_waka) June 16, 2023 やってきたことはこの辺のスライドによくまとまっている。 https://speakerdeck.com/waka/da-kinapurodakutofalseyu-tefang 社員5人から1000人になったり、ARRゼロ円からARR200億円になったり、ヤバかった品質をどうにか底上げしたり、開発本部長の立場で上場を経験したり、普通では経験できないことを濃度高く経験できて楽しく過ごせた10年だった。 freee会計という業務系Webサービスを10年間機能面/パフォーマンス/品質面共に育ててきた経験

<span title='2024-01-17 00:00:00 +0900 +0900'>2024年01月17日</span>&nbsp;·&nbsp;5 分&nbsp;·&nbsp;2053 文字 身近な人がデジタルデトックスをやるということを聞き、自分もこれは必要かもしれないかもなと感じたため、自分なりにデジタルデトックスもどきを実践してみています。 実践し始めて１週間ちょっとしか経っていないですが、すでに多くの良い変化を感じられているのでメモしておこうと思います。 なぜ始めたか、何をしているか#はじめに述べたデジタルデトックスすると言っていた人と話している中で、自分は短時間で得られる刺激に悪い意味で慣れてしまっていることに自覚的になりました。 例えば、YouTube Short や Twitter、インスタのストーリー、社内の Times など。 短時間で得られる刺激を摂取しすぎて

(DALL-E3によって生成しました) この記事はpyspa アドベントカレンダー 2023の4日目です。 昨日は@tokibitoでした。 ペーパードライバー 私は20年前に免許を取って以来、車を運転したことは片手で数えられるレベルの完璧なペーパードライバーでした。 結婚して子供ができてからも旅行はいつもタクシーや公共交通機関を利用していましたが、今回は軽井沢へ旅行をすることになったので、久々に車を運転してみることにしました。 準備 運転に関してはほぼ初心者だった私は、以下のステップで準備を進めました。 ペーパードライバー講習 実際の車を使用して、基本的な操作や運転のコツを学びました。 ペーパードライバー講習は現地にいかなくてもわざわざ近くまで車で来てくれて、最後は自宅前で終了できるという非常に便利なものでした。 また、子供を連れて乗ってもOKとのことだったので（チャイルドシートも用意し

最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは

*1 サーバーレスFunctionsぐらいの気軽さでサーバーアリのWebアプリをデプロイしたいという時がある。主に自分たちだけが使うようなツール系のやつ。 その時に今までのようにSPA+APIアーキテクチャではなく、モノリシックなサーバーサイドアーキテクチャにしつつもフロントエンド開発と同じツールチェインを使いたい、と前から思っていた。 これは単にReactメタフレームワークでも一気通貫に時短で作れそうだけど、個人の楽しみのための活動なので、一旦世間のトレンドからは離れて自分が本当に必要だと思った要素技術のみを最小限に使って理解しながら試行錯誤したい。 ※ただ第三者に提供するシステムとかは安全に作られた既存フレームワークに乗るのがいいというのもある しばらく考えてみたところ、私にとっては「TypeScriptでJSXをテンプレートエンジンに使ってHTMLを書けるだけでよい」という所に落ち着

2022年10月1日に開催された #postdev での発表です

ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「RESAS API を使用して、都道府県別の総人口推移グラフを表示するSPAを作る」っていうお題 React の勉強をするのにちょうどいい題材だなぁって思ったのでやってみた。課題を公開してるってことは「やってみてもいいよ」ってことかなと思ってるんだけど、もし違ったら GitHub のリポジトリーを private にするので連絡ください 1週間でやらないといけないところを2ヶ月近くやってるし、コミットログも特に何も考えずにポイポイ書いたから、全然だめなんだけど、でも、色々勉強になったので、とてもよかった。楽しかったー！ つくったもの こんな感じ これでおわりにするー pic.twitter.com/K8zhrRUp54— Mitsuyuki Shiiba (@bufferings)

このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性

こんにちは。CTOのid:motemenです。みなさん趣味プログラム書いてますか？ このエントリは Backyard Hatena #4 のフォローアップ記事です。エピソードの最後のほうで、「motemenが作って公開しているツール、どんなことを考えて作ってる？」という話になりました。そのときは時間の関係もあってあまりちゃんと話せなかったな、という感覚があったので、ここであらためて考えてみようと思います。 治具のようにつくる ウェブ上で読める自分が好きな記事のひとつに、Go Is a Shop-built Jig（抄訳）というものがあります。一言でいうと、「Goは現実的な問題を解くための治具である」ということをいっています。治具とは何かを達成することを補助する小さな目的のために作られた道具、という感じかな。fujiwaraさんの隙間家具のたとえからも近いニュアンスを感じます。 自分がツール

コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。

自分は、仕事でScalaを数年間・プライベートな経験を含めると10年弱のScalaの経験がある、そこそこの熟練Scalaエンジニアだ。チームにメンバーが入ってきたり他人に勧めるたびにScalaの環境構築を教えている一方、最新の知見を反映した記事が無くて他人に勧めづらかったので、自分が書くことにした。 現在ある記事 けっこう古びている 覚えながら書かれていることが多いのでやや曖昧な箇所がある(でもありがとう！) 最新のツールが利用できておらず無駄が多い 網羅的でない 今回目指す内容 最新の知見を活用して最短距離を目指す 何もない状況から一通りのツールが揃う所を目指す Scalaの環境構築は年を追うごとに簡単になってきているので、大多数の読者は引っかからずに進めるようになっているはず。 Scalaは基本的にJVMで動作する言語だ。このため環境構築にはJVMのセットアップも含まれるのだが、それに