発表資料「日付時刻A to Z」を公開しました | Wantedly Engineer Blog
日付や時刻データの扱いについてまとめたスライド「日付時刻A to Z」を作ったので公開します。 これは何？「日付と時刻」を正しく扱うために、日付/時刻にまつわる諸概念やありがちな間違いを紹介したスライドです。このスライドは大きく3つのパートに分かれています: 第1部「日付編」§1 天体の周期§2 暦§3 紀元と通日第2部「時刻編」§4 時間と分§5 秒§6 相対性理論第3部「コンピューティング編」§7 文字列表現§8 数値表現§9 時刻同期第1部と第2部では、「日付」や「時刻」の概念を定めるのに必要な知識を整理します。第3部ではその日付時刻をコンピューターで扱うときに特有の事情を補足しています。 このスライドが作られた経緯ウォンテッドリー社内では毎週1回お昼の時間に任意で集まって技術の話をする "Tech Lunch" というイベントがあります。テーマは自由で、社内でやったことの紹介やアナ
GitHub、WebIDEの「Codespaces」を発表。GitHubからワンクリックで開発環境へ。GitHub Satellite 2020
GitHub、WebIDEの「Codespaces」を発表。GitHubからワンクリックで開発環境へ。GitHub Satellite 2020 GitHubは、Webブラウザから使える統合開発環境「GitHub Codespaces」を発表しました。 Introducing GitHub Codespaces, a complete dev environment within GitHub that lets you contribute immediately. You’ll be up and developing in less time than it takes to read this post. #GitHubSatellite pic.twitter.com/RIt7rRbzpP — GitHub (@github) May 6, 2020 GitHub CEOのNat
コードレビュー ありがちな問題への対処例 - Crieit
コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。 指摘事項について よくある話 - 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない - 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう - 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう この辺はみんな知ってると思うので略。ぼくが思う大事なルール コードレビューで指摘された内容は、対応必須ではない 理由： 対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。 絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがあ
「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう － Publickey
「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう これはもともとGitHub社内で行われていた運動を広げ、誰でも参加しやすいようにしたもの。 下記はOpen Source Fridayの提唱を紹介する同社ブログの記事「Contribute on Open Source Friday · GitHub」からの引用です。 Over the last three years, we've encouraged GitHub employees to take time at least every fourth Friday to work on open source and share what we're working on with each other. Open Source Friday has grown from t
デッドコードは取り除かなければならない
デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。Kevlin Henney氏によると、それは考え方と文化の問題だ。 独立したコンサルタントでトレーナであるKevlin Henney氏が、ヨーロッパテストカンファレンス 2017において、基調講演「やり方の間違い」を行った。この基調講演で、デッドコードが実行されたために、ある企業が何億ドルもの損害を被ったことを発表した。 InfoQは、このカンファレンスをQ&A、要約、記事で扱う。 ソフトウェアの失敗は、個人的に不便だったり、迷惑だったりするが、経済的、または、社会的に重大な影響を与えることもある。Henney氏は、小さな不具合のせいで、何百万ドルもの損害を出した例をいくつか
今あえて試行錯誤しながら"車輪の再発明"をする意味 #jtf2016
#jtf2016 ( http://2016.techfesta.jp/ ) にて『今あえて試行錯誤しながら"車輪の再発明"をする意味』というタイトルで発表しました。
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
RE: クソコードと呼ばない - 更新終了 過去アーカイブ
例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。 ホントそれ。びっくりするほど簡単に場を汚染してしまうので、意識的に避けている。 さて、昨年末に公開されたこの記事 2ページ目で自分に言及があり、 「悪いことを言わない」という前向きな思想が彼にはあるんだろうね。ネガティブなことを口に出してしまうと「言霊（ことだま）」となって固定されてしまうと考えているんだね。 という評価をいただいた。 「悪いこと」ワードを発する事によって、雰囲気を悪くしてしまうのを恐れている。場を悪い方に倒してしまうことを強く恐れている。 どんなものであれ物事は放っておくと悪化して行く。滅び方向に向かっていく。 それを食い止めて自分たちの望む方向に持っていく活動を環境面であれ技術面であれ行っているわけだが、わざわざ悪化させる必要なんて無い。非常にシンプルなことだ。
クソコードと呼ばない - ppworks.jp
新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら
Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
何でもデバッグできるようになるスキル - ワザノバ | wazanova
https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ（apt, yum, gem等）レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい
スクールガールストライカーズの 内製クライアントエンジン
近年、ハイスペックなスマートフォン、高品質なネットワークが普及し、それによりモバイルゲームの制作手法やそれを取り巻く環境も変化してきました。スクウェア・エニックスでは、そのような環境の変化に対して、日々新たなチャレンジをし続けています。そして、このようなスピード感溢れる業界の流れには、会社の枠を超えた技術情報の共有、交流が欠かせないと感じております。 そこでこの夏、社内のエンジニア・テクニカルディレクターによる最新のモバイル開発の技術情報や社内モバイルエンジン、開発秘話によるセッションをメインに、スクウェア・エニックス モバイル オープンカンファレンスを開催する運びとなりました。また、セッションの後は登壇する弊社スタッフと直接ディスカッションやフリートークができる場を設けております。この機会にスクウェア・エニックスという会社についても、より詳しく知って頂ければ幸いです。 マネージャー・テク
個人開発と徳
主催・運営した エムスリー x Gunosy Beer bash！ の発表資料です＾＾ gunosy-beer.connpass.com/event/22825/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
宮崎県の統計システムの公募がすごい。
Test::Unitでテストを書く - Qiita
CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」