現行のインボイス制度に関するSkebの対応につきまして
いつもSkebをご利用いただきありがとうございます。 2023年10月1日よりインボイス制度(適格請求書等保存方式)が開始されます。現行のインボイス制度に関するSkebの対応をお知らせいたします。 このお知らせはインボイス制度の解説を含み、非常に長い説明となっているため、先に要点を記載させていただきます。 要点Skebは現行のインボイス制度に強く反対します。インボイス制度は「クリエイターの本名がファンにバレる問題」「消費税の納税義務を負うか、取引が不利になるか二択を迫られる問題」「事務負担が増える問題」などクリエイターのみなさんにとって問題点が多く、十分な議論がなされないまま開始されようとしています。Skebでは特例制度を活用し、上記の問題を解決します。 Skebを利用する取引に限っては、クリエイターのみなさんの本名が登録番号経由でクライアントのみなさんにバレたり、インボイスに対応していな
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
【プライベートLTE】第1回：プライベートLTEって何？ ~概要&デモ環境の紹介~
■ はじめに…こんにちは，NTT研究所の本村です．私はプライベートLTEに関する研究開発に取り組んでいます． 皆さんはプライベートLTEを知っていますか？？ 「LTE(Long Term Evolution)ならスマホで使っているけれど，プライベートLTEって単語は聞いたことがない…」 という方も多いのではないでしょうか． 普段皆さんがiPhone等で利用されているLTEサービスは，基本的にモバイルキャリアにより提供されているものです．一方で，現在では免許不要で設置可能な無線基地局の商品化やコア網設備のOSS開発が進み，個人や企業などの非モバイルキャリアでも自営でLTE設備を構築可能となりつつあります．このようなモバイルキャリアの設備を利用せず自営の設備で自社/個人専用のLTEネットワーク(≒オレオレLTEネットワーク)を構築する仕組みがプライベートLTEです． プライベートLTEは「情報
真面目な人を本気にさせる方法
先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに「本気（マジ）と真面目（マジメ）」の話を聞いた。 この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。 TL;TRありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。 本気と真面目 人はドキュメントを前にして真面目な態度を取るが、動くソフトウェアを前にして本気になる。端的に言うと、人は仕様書などドキュメントを前にするとそれを徹底的に重箱の隅を突くようなレビュー（真面目）をしてしまうが、本当に欲しかったことに対して考え始める（本気）は実際のプロダクトを前にしてからという話だ
プログラミングを教えるときの10のポイント (という論文の紹介)
1. ギークの遺伝子なんてないことを心に留めようよく、「プログラミングには得意不得意がある(some kids get it, and some kids don’t)」とか、さらには「プログラミングには向いていない子がいる」とか聞きますね。 大学のコンピュータサイエンスの授業の成績分布が、とても良く理解できる生徒と何もわかっていない生徒にくっきりわかれる、という話も聞きます。本当でしょうか？Patitsasらの最新の研究によると、実際にはそんなことはなく、くっきりと成績の分布が分れてしまったコンピュータサイエンス入門のクラスは、5.8％に過ぎなかったそうです。 この論文では、「プログラミングには得意不得意がある」という迷信は、プログラミングを学びだしたときに躓きがちな生徒でなく（意識的か無意識的かにかかわらず）、スムーズに学ぶ生徒の方へ教える時間や熱意を費やすことにつながり、ひいてはコン
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
5 Reasons Why We switched from Python To Go
Gophers from golang.orgPython is awesome! Especially Python 3 with async functionality. But really Go is not giving any chances to survive in enterprise world… If you got the idea of this quote, then you probably tried or just looked around Go programming language. Which is I think easiest programming language that can fit in any kind of application development. Yes! you read that right, for me Go
いいアイデアなんか思いつくはずがない
インタビューや観察の結果を整理する方法として「親和図法（affinity diagram）」がよく用いられます。また、そこからチームでアイデアを出す方法として「ブレインストーミング（brainstorming）」が用いられます（そこから再び親和図法に戻ることもありますね）。いずれも有名な手法なので詳細は省きますが、付箋紙をホワイトボードにペタペタ貼りながら、みんなでワイワイやるようなイメージです。 https://www.flickr.com/photos/jakecaptive/49915119よく用いられるからには、きっとそれなりの理由があるのでしょう。ですが、私はいずれに対しても（めちゃくちゃ）懐疑的です。使っていないわけではないのですが、使ってもいまいち感が残るというか、まるでうまくできる感じがしないのです。こんなのでいいアイデアなんか思いつくはずがない。それこそ「机上の空論」みた
なぜ優秀なエンジニアを低待遇で採用してはいけないか
この記事は技術そのものやエンジニア採用のことがよく分からない経営者へ向けて書いています。エンジニアが読めば当たり前のことが書いてあります。また優秀なエンジニアならこう考えるのではないかというところは、私見によるものなので本当にそうかどうかは分かりません。 募集要項を書く募集要項で最も重要なのは待遇に関するところだと私は思います。具体的に言えば、だいたいの年収です。もちろん業務内容や組織の雰囲気なども重要ですが、業務内容や組織の雰囲気が良ければ年収が低くても働こうと思ってくれるのではないかと考えるのは経営者の奢りであって、そんなエンジニアはほとんどいません。優秀なエンジニアにとってはそのどちらも満たす求人が他にたくさんあるために候補にすらなりません。 逆に業務内容に魅力がなくても年収さえ高ければ良いという優秀なエンジニアも一定数いるはずです。待遇を具体的に書くことはそういった層に響くのではな
「やってみないとわからない」という思考停止
「やってみないとわからない」だから、試すんだ。そのことは間違いじゃない。確かにその通り。 立派な計画を立てても実行しなければ、1ミリも社会に影響を与えない。 頭でっかちにならずトライアンドエラーで、逐次修正しながら進めよう。 アジャイルにやっていきましょう。少しずつ小さく試していけば大丈夫。 そう、世の中には、やってみないとわからないことばかりだ。正解が決まっていないことの方が多い。 だから、やってみる、行動してみるということに価値はある。 ・・・だけど、それ、本当にやってみないとわからないことなのか？と考えたか。「やってみないとわからない」といって、考えてみることも放棄してないか。 考え尽くしたあとに、やってみないとわからないことを試さないと、やってみたことが良かったかどうかもわからない。 やってみることに仮説があるかどうか。 なぜやるのか。仮説をもって取り組めば、仮説が正しかったか、間
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
