ひよ子のにわとり進化ピックができるまで - やみなべノート
こんにちは。たばねです。 ひよこをにわとりに進化させるピックを作りました pic.twitter.com/2KJ06QTkNx — たばね (@_tabane) 2020年1月24日 先日作ったこのピック。予想以上の反響をいただきびっくりしてます。本当にありがとうございます。 販売と作り方について多くお声をいただいたのですが、販売するほどのものでもないので作り方だけ簡単に記載します。最後にカット図も置いておくのでぜひ使ってください。 1.発案 発案の過程は全然覚えていませんが、ひよ子饅頭で何かしようとしてたメモがあります。 「ひよこ砂遊び」は話題のネコカップ↓をひよ子の形でやりたいなというメモでした。 https://koncent.jp/?pid=144026926 おそらく作らないのでひよ子本家様がやってくれる事を楽しみにします。 2.データ作成 データ作成の時点で手元にひよ子がなかっ
２つのことを同時に学ばない
こんにちは、ある人のところてんです。プロシンという情報処理学会の<s>新年会</s>学会にかれこれ15年くらい参加しているわけですが、本稿はそこで水島さんと話をした「2つのことを同時に学ばない」という考え方についてのまとめになります。 初手レイトレーシング「２つのことを同時に学ばない」というのは私が発した言葉ですが、この言葉には私の友人の影響があります。 私の友人に「新しいプログラミング言語を覚える際には、とりあえずレイトレーシングを書いてみる」と言うやつがいます。 彼にとってはレイトレーシングのコードは、資料を何も調べずとも書けるそこそこに複雑なコードという位置づけのようです。 そのため、彼にとってはレイトレーシングを新しい言語で書くことで、言語仕様にのみ問題を絞って勉強することができるわけです。仮に実行結果がマズかったとしても、それは言語仕様の理解の問題であり、アルゴリズム自体に問題な
テストのためだけに`interface`を書きたくないでござる — KaoriYa
golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。 Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface
良いコードの書き方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数
【edvakf×harukasan対談】ピクシブCTO交代の舞台裏と彼らの描く未来 - pixiv inside
2020年1月1日より、ピクシブ株式会社のCTO（最高技術責任者）が交代いたしました。 www.pixiv.co.jp 今回は、2016年12月よりCTOを担ってきた高山と、新しくCTOとなる道井に、今後の抱負などを伺いました。 まずは、お二人の自己紹介をお願いします。 高山 高山（@edvakf）です。ピクシブに入社したのは2012年3月で、CTOは2016年12月から3年ほど務めていました。 道井 このたびピクシブ株式会社CTOに就任しました、道井（@harukasan）です。2012年4月に新卒としてピクシブに入社しました CTO引き継ぎの背景 早速ですが、CTO退任の背景を教えてください。 高山 ピクシブでは約8年働いたのですが、信頼してもらえてずっと大きな役割を任せてもらえました。ただ、長く務めているとどうしても居心地の良い環境に甘えてしまうところもあり、新しい場所でもっと自分の
pixivに脆弱なパスワードで登録できないようにしました - pixiv inside
図1: 脆弱なパスワードを入力した場合のエラー画面 こんにちは、pixiv開発支援チームのmipsparcです。 パスワード、もしかして使いまわしていますか? 複数のサービスで同じパスワードを利用していると、「パスワードリスト型攻撃」によって不正アクセスの被害を受けてしまうかもしれません。 パスワードリスト型攻撃の被害にあわないためには、ブラウザやパスワード管理ツールで自動生成された安全なパスワードを利用するのが好ましいです。 しかし、実際には多くの人が「使いまわしたパスワード」や「簡単なパスワード」(以下、脆弱なパスワード)を利用していますし、啓蒙活動にも限界があります。 pixivではサイバー攻撃への対策を複数とっていますが、根本的な対策のひとつとして、脆弱なパスワードを新しく設定できないようにしました。 脆弱なパスワードの判定方法 脆弱なパスワードの利用はどのように防ぐことができるで
ブックマークの全削除機能の提供を再開しました - はてなブックマーク開発ブログ
いつもはてなブックマークをご利用いただき、ありがとうございます。 本日、ブックマークの全削除機能の提供を再開しましたので、お知らせいたします。これまで本機能はアプリケーションの不具合により、勝手ながら一時停止させていただいておりました。ご利用の皆様には、長期にわたってご不便をおかけしたことをお詫び申し上げます。 ブックマーク全削除の手順 ブックマークの全削除は、以下の手順で実行できます。 「設定 → データ管理 → ブックマークの全削除」から「削除を進める」をクリックします 全削除の実行を再確認するダイアログボックスが表示されます。全てのブックマークを削除してもよい場合、「OK」をクリックします 注意事項 ブックマークの全削除にあたっては以下の点にご注意ください。 削除されるデータは、ご自身のブックマーク、コメント、タグのデータです お気に入り・お気に入られユーザーの情報や、あとで読むリス
チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました | DevelopersIO
チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました 事業開発部の塩谷 (@kwappa) です。 クラスメソッドの関連会社であるアノテーション株式会社の研修として依頼を受け、チームと心理的安全性、それに礼節というテーマで話をしてきました。 スライド 概要 ここしばらく重点的に書いたり喋ったりしている、心理的安全性とその土台となる礼節がテーマです。昨年のDevelopers.IO Tokyo 2019でのセッション『3つの「Re」〜ソフトウェアの信頼性を高めるためにぼくたちができること〜』 をベースに、発表時間が少し長くなったので各要素の解説を丁寧にしつつ、全体の流れを整理しています。 また、エンジニアに特化した部分をはがすことも意識しています。チームで仕事をするのはエンジニアに限ったことではないですし、昨年末からOpsチームのスクラムマス
Launchableからこんにちは - 川口耕介のブログ
2020年は僕にとって転機の年になります。というのも、今月末でJenkinsプロジェクトからは一歩退き、CloudBeesでは顧問に退き、そして新しい会社Launchableを始めるからです。 思えばJenkinsは色々な人のおかげで言い出しっぺの僕の予想を遥かに超えた大掛かりなプロジェクトに成長しました。本当に子供の成長を見るような思いです。だから、いつからか、僕としては後をどうやって引き継ぐかを考えるようになりました。今日、コミュニティとCloudBeesのおかげで、新しいボードメンバー達であったりJenkins Xであったり、コミュニティに新しいリーダーが育っています。なので、安心して彼らに今後を託す事が出来ます。実際の所、2019年中から徐々にプロジェクトから手を引き始めて色々な事を色々な人に任せてきたので、この発表で何かが突然大きく変わるということはありません。引き続きJenki
より美しいコードを書くことに対する感情を失ってしまったのは衰えか成長か - まいくろ🍣きりみん
昔：感情があった 元々ぼくはきれいなコードを書くことへのモチベーションが高かった。 プログラマーになったばかりの頃にリーダブルコードを読んで感動したというのもあるし、ちょうどその頃DDD原理主義みたいなものが流行ってて、はてブのITタブにはきれいなコードを書くためのコーディング規約やテクニックに関するブログエントリやLT資料がたくさん流れていた。 最初にAndroidの大規模プロジェクトに関わった時は、元々のコードがかなりひどかった(初めてJavaを書く人達だけで書いたとしか思えない、現代ではおおよそあり得ないようなレベル)ため、リファクタリングをすることに非常に意義もやりがいも感じたし、どうせきれいにするのならばと張り切って出来るだけリーダブルなコードを書こうとした。 その後チームにgit化の波が訪れ(自分が推進したんだが)PRによるコードレビューなるものもやるようになった。 意識が高か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
え？待って？エンジニアの人って会社行くのにスーツ着ないの？スーツの２割増効果使わずに私服で勝負するの？