フリーランスにとって「ちょうどよい」を目指した会計ソフトです。 難しい会計のことを知らなくても、日々の業務に忙しくても、 他の会計ソフトみたいに高いお金を払わなくても、 業務と切っても切り離せない「会計」が Shiwake だけで。

たまに Rust の勉強もかねて何かを再実装しようと思うんだけど、大抵は途中で飽きてしまう。一方で、最近に仕事で使っている雑なスクリプトをきれいに書き直して、これはなかなか楽しかった。というわけで、自分の中での楽しさを書き出してみようという試みです。 自分の生活が便利になった 仕事で書くスクリプトとか、個人的な便利コマンドとかはここの楽しさが大きい。 仕事で関わって製品としてリリースされるものが、自分の生活を便利にするかは、まあ半々くらい。「確かにこれあるといいですね。自分でも使います。」というものもあるし、正直いって自分は使わなそうなものもある。 コンシューマ向け製品だと、自分の好みはだんだんメインストリームとずれてきていて、それは将来に不安を感じる。携帯電話のプッシュ通知とか、なるべく来ないで欲しい。 無理そうなことが出来てかっこいい 昔に作っていた、SIMBL で Mac のアプリを
Kamran Ahmedのブログより。 ジュニア、中堅レベル、またはシニア開発者としてステップアップするには? カムラン・アーメッド (Kamran Ahmed) 私はロードマップのやり直しに取り組んでいます —— 年功レベルに基づいてスキル一式を分割し、新しい開発者に理解しやすくし、怖がらせないようにします。ロードマップは技術的な知識についてだけになるので、私が繰り返し、様々な年功の役割について考えていることについて記事を書くのは良い考えだと思いました。 私は、多くの組織が長年の経験を本来あるべきものよりも重要視することで開発者の年功を決定しているのを目にしてきました。私は、「ジュニア」とラベル付けされた開発者がシニア開発者の仕事をしており、「シニア」と呼ばれる資格さえない「主任(lead)」開発者を見てきました。開発者の年功は、彼らの年齢、経験年数、または彼らが持っている技術的知識だけ
プログラマ35歳定年説が滅びたいま、我々技術者の前に立ち塞がるのは「老眼」です。 諸先輩方を中心に貴重な経験談やアイデア等多数いただきましたので、ざっくりとジャンル分けしてまとめました。誠にありがとうございます。 (どなたでもまとめ編集可にしてありますので、問題がある場合は削除や編集などしていただければと思います)
GitHubは、オープンソースソフトウェアの開発に携わる開発者に経済的な支援を行えるサービス「GitHub Sponsors」がベータ版を脱し、日本を含む30カ国で正式サービスになったことを発表しました。 GitHub Sponsorsは、支援を受ける「スポンサード開発者」に対して、あらかじめスポンサード開発者が設定した月次の支払金額などを寄付することでGitHub上で経済的支援が行えるサービスです。 また、オープンソースのコントリビュータが質問に答えてくれた時や問題をトリアージしてくれた時、あるいはコードをマージしてくれた時などにも、そのコントリビュータのプロファイルに移動するか、ユーザ名にカーソルを合わせるだけで、資金援助を行うことができます。 オープンソースプロジェクトにコントリビュートしている人は誰でも、将来スポンサード開発者になる資格があり、自分のGitHubリポジトリのページに
ポエムです。 アウトプットに挫折してしまう人 現代のインターネット社会において、特にエンジニアなどの技術職の場合、アウトプットをすることが大切とよく言われる。 ここでいう「アウトプット」というのは、例えばブログを書いたりだとか、作品を作ったりだとか、発表をしたりだとかだ。 しかし、アウトプットをするというのは向き不向きがあるようで、苦手な人も多いようだ。 純粋にアウトプットが性に合わないという人もいて、そういう場合はそれはそれでいいと自分は思う。 決して自分の成果や能力をオープンにアピールしなくても優秀な人はたくさんいるし、そういう人は有名ではないけれど確実に評価されきちんと仕事を得ている。 一方で、アウトプットをして承認されたいと思っていながら、それが上手く出来ない人というのもいるようだ。 自分の観測範囲だと、特にアウトプットのハードルが上がりすぎていて、その高いハードルを乗り越えた結果
なんか京都に移住することになった 明けましておめでとうございます。 突然ですが、京都に住むことになりました。 理由は家庭の事情です。我々はもう親から車の免許を取り上げるとか、同居とか介護とか、 そういうことを考えなければいけない年齢なんですよ……。 さて、気になる職についてですが、FA 宣言させていただく形になりました。 まだ在職中で最終出社日も決まっていない異例の記事ですが、 引っ越し日程から逆算して次の就職先(=通勤経路)を決める必要があるのです。 今後に関して まだ何も決まっていませんが、2 月中旬には決めちゃう感じのスピード感です。 京都にオフィスのある会社 フルリモートの実績がある会社 のいずれかで働きたいと思っています。 他の要素としては 開発言語には特にこだわりはありません。Ruby だと今の知識が全て活かせるのでマッチしやすそうです サーバサイド/クライアントサイドにもあま
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます! と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
Ruby/Railsと直接関係ありませんが、かつてRubyコミュニティで愛された_why氏の名言を紹介したいと思います。 when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create. – Why the lucky stiff (何も作っていないとき、人は自分の能力よりも好みによって特徴付けられることになる。好みは世界は狭め、他人を排除するばかりだ。だから、作れ) これは2005年頃から2009年にかけてRubyコミュニティで「Why the lucky stiff(_why)」のペンネームで活躍していた、ある多才なRubyistのツイートです。 発言の文脈が分からないので、もし
テクノロジの流行をファッションに例えて揶揄することがある。新しいテクノロジを追いかけてばかりいるプログラマを非難し、勉強会もいいけど問題解決に頭を使えという。 ファッショナブルなプログラマを責めるのは、衣服や装飾品で散財する人を無駄遣いせず金を貯めろと責めるのに似ている。ユニクロ・無印・(その他無難なブランド)でいいじゃん、それより体でも鍛えなよ、なんて説教するかんじ。一理ある。でも話が通じる気はしない。 おしゃれ貧乏はさておき、人々はなぜ身だしなみに気を使うのだろう。周りと同じがいいなんて消極的な理由もあろう。特定の文化的集団、サブカルチャーに参加するためかもしれない。反対に人と同じが嫌だからかもしれなければ流行りに詳しいところを見せたいからかもしれず、単に目立ちたいからかもしれない。演出したい自己像を求める人もいれば洋服マニアもいる。防寒や衛生や法令遵守だけが衣類への期待とは限らない。
現在趣味で Web サービスを作っています。今年の 4 月末くらいから準備をし始めていたので、かれこれ 4 ヶ月くらい開発を進めています。一人きりの開発+完成したとしても実際に使ってくれる人がどのくらいいるか分からないという状況ですが、なんだかんだ楽しみながら作業できています。 まだ完成もしていないので、こんな事を書くのは的外れのような気がしますが、やる気の枯渇を防ぐために自分なりに気をつけていること+やっていることを書き出しました。既に色々な方が書いているような内容なのであまり目新しいものでは無いかもしれません、あくまでも僕なりの内容となっています。 自分が使いたいものを作る 凄い基本的なことですが、凄く大事なことのように思います。今作っているのが、主に Web サイトのデザインをアーカイブしておくための(Pinterest みたいな)サービスなのですが、少し前から欲しい欲しいと思ってい
一昨日、福井県の「ふくい産業支援センター」さんが主催されたセミナーで、標題の講演をさせていただきました。資料はこちら。 参加者約70名のうち、75%は18歳以上の大学生・専門学校生、15%が高校生・高専生、10%が小中学校。これまでエンジニアの中で話をする機会は多々ありましたが、学生さんばかりの中で話すのは初めてでした。 内容 内容としては、「プログラミングでこんな感じでメシを食ってる人がいる」という一つの参考例として自分の働き方を紹介しつつ、プログラマとしてとりあえずやっていけるようになるまでの話と、フリーになってからおもしろい仕事を得るためにどんなことを考えながら働いているか、の3部構成でした。 50分と長尺の講演だったので、最後にFAQをくっつけて時間調整できるようにしておいたのですが、6つぐらい用意しておいたうち2つぐらいしかしゃべれず。話したうちのひとつは「お金の話」だったのです
みなさんはプログラマーの三大美徳ってご存知ですか? プログラミング言語Perlの作者である Larry Wall が↓で述べたのが最初とされています。 http://www.perl.com/pub/1998/08/show/onion.html 三大美徳として 怠惰(laziness) 短気(impatience) 傲慢(hubris) があげられています。 今回はそのうち怠惰(laziness)についてお話します。 怠惰(laziness) 怠惰といえば怠け者。怠け者といえば怠け者メガネ。怠け者メガネを使えば誰でも簡単に美徳を手にいれることができます。 この怠け者メガネを使うと視線は前方に向けたまま下方を見ることができます。 本来は寝転がってテレビを見るために開発されたようです。 この怠け者メガネを使ったプログラム開発について説明します。 レベル0 怠け者メガネを装着せずに作業します。
オライリージャパンより献本御礼。先日、新沼氏とお会いした際に頂いた。本書は実にに素晴らしい内容であり、私を含む、すべてのIT屋が反省して読むべきである。いや、正確には私はもう読んだので、後は反省するだけである。 一生現役で居るには プログラマに限った話ではないが、ずっと現役で働くには健康でなければならない。身体を壊して入院生活を送らなければならないようでは、労働することはもっての外である。プログラマは高い集中力が求められる職種であるが、目の前のことに集中するという点でも、健康は欠かせない要素である。 以前、アレルギー紫斑病を患ったとき、1ヶ月ほど出歩くことが出来なくなってしまった。病気自体も辛かったのだが、それよりも危機感を覚えたのが、出歩かなかったことによる身体の衰えである。筋肉は、動かさないとあっという間に衰えてしまう。一説によると、4週間寝たきりになると、88%も筋力が低下してしまう
みんなのウェディングの高井です。 最近、若手のエンジニアと話をする機会が多くあります。そういった場で、ここが重要ですよと伝えたい話のうちのひとつがこの話になります。別のところに書いていたものですが、すこし手を入れた上で再掲します。 ハッカーの世界には昔から「RTFM」という言葉があります(参照)。ようするに「マニュアルを読め」という言葉なのですが、これはとても重要な言葉です。 色々な人によってブログにメモやノウハウが記載され、簡単に検索でみつかる世の中ではあります。また、そのためのサービスや技術的な質疑的な質問をすることのできるサービスも沢山あります。 しかし、検索サービスは、その内容が正しいことまで保証してくれません。見つかった記事の著者が誤解している場合もあれば、理解していない場合もあります。そして、ほとんどの場合は最新の情報ではありません。 マニュアルや公式ドキュメントであれば、それ
このプランは、自分たちが働きたいソフトウェア会社を作るためにFog Creekをはじめた私たちにはとても都合のいいものだった。当時の私の主張は、良い仕事環境を作ることで(照れずに言うなら「世界中の優れたソフトウェア開発者たちが働きたいと思うような会社を作る」ことで)、収益は自然にもたらされるものであり、それはチョコレートが肥満をもたらしたり、テレビゲームのセックスシーンが暗黒街の殺し合いをもたらすのと同じことだ、というものだった。 今日のところは1つの疑問にだけ答えることにしよう。もしこの部分が間違っていたなら、理論全体が崩れてしまうからだ。その疑問とは、「最高のプログラマ」を雇うということにそもそも意味があるのか、ということだ。最高のプログラマを求めることが重要な意味を持つほど、プログラマの能力の違いは大きいものなのだろうか? この疑問に対する答えは私たち開発者には明らかなことかもしれな
サイボウズに在籍する技術者を紹介するインタビューシリーズ。 光成滋生(Shigeo Mitsunari) 2007年7月、サイボウズ・ラボ株式会社に入社。 「キーの数が多い」という理由で日本語配列キーボードを愛用。「:」キーにバックスペースを割り当て、「変換」や「無変換」キーをAltやCtrlのような(他のキーと組み合わせて押すことで機能する)Modifierキーとして活用するなど、徹底的にカスタマイズしている。 プログラマには、1つのプロジェクトだけに長く携わり続ける人もいるが、異なる複数の技術やソフトウェアを世に問い、マルチな才能を遺憾なく発揮する人も少なくない。たとえばPerlのオリジナル作者として著名なLarry Wallは、今では「パッチを当てる」という普通の表現にもなっているpatchコマンドを作ったことでも知られている。また、Linuxカーネルを最初に作り始めたLinus T
あるとき Dark Matter Programmer という言葉をみかけた。ウェブやコミュニティに存在感のない、当人もそれを気にかけていない、プログラマをさす言葉。言い出しっぺの主張は、そういう人々の存在を忘れたり、見下したりすべきでないというものだった。 ダークマターはうまい比喩だと思う。正体がよくわかっていないらしいから適当さの粗が目立たず、その割にイメージは鮮烈。 他の比喩との相性もいい。たとえばスター。スタープログラマはダークマタープログラマの対極にいる印象だけれど、意図に立ち戻ればそれほど大げさでもない。何らかの可視性があればスターといえる。僕もあなたもスターなのがオンラインのコミュニティなのだろう。 さまざまな星 なんてきれいごとはさておき、乱暴に言ってダークマター以外がスターならスターにも色々ある。細かい隕石やガスなんかをさておくとしても、まず明るさ、等級が違う。あるいは自
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く