9時間足すんだっけ引くんだっけ問題～あるいは、諸プログラミング言語はいかにタイムゾーンと向き合っているか - エムスリーテックブログ
私は日付時刻の処理が大好きです。 タイムゾーンの問題でデータ抽出が9時間分漏れていたとか、朝9時の始業前のログが昨日付けになってしまっていたなんていう問題が起こると喜んじゃうタイプ。 そんな私にとって、各プログラミング言語が標準で持っている日付時刻型クラスにはそれぞれ思うところがあり、今日はちょっとその品評会をしてみたいと思います。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の2日目です。 至高の日付時刻型を持つ言語、BigQuery SQL 不足はないが蛇足、Java 8 日付時刻で画竜点睛を欠いたC# C#よりややまし、Python 型は良い構成、なのに命名と処理関数で損しているPostgreSQL まとめ We ar
neue cc - async decoratorパターンによるUnityWebRequestの拡張とUniTaskによる応用的設計例
UniTask v2も2.0.30まで到達し、いい加減そろそろ安定したと言える頃合いです（ほんと！）。GitHub Star数も1000を超えて、準スタンダードとして安心して使ってもらえるレベルまで到達したと思うので、基盤部分から入れ込んで設計するとこんなことができますよ、という一例を出してみます。 UnityWebRequestはかなりプリミティブな代物で、そのまま使うよりかはある程度はアプリケーションに沿ったラッパーを被せることがほとんどなのではないかと思います。しかし、ライブラリ単体でアプリケーションの要求を全て満たそうとするとヘヴィになりすぎたり、というかそもそもアプリケーション固有の要求には絶対に答えられない。というわけで、理想的なラッパーというのは、それ自身が極力軽量で、拡張性を持たせたプラガブルな仕組みが用意されているものということになります。プラガブルな拡張性がないと、例え
TypeScriptのanyみたいな「なんでも代入できる型」を分類する - soutaroブログ
安全でないもの - void * (C) いろいろあるんだろうけど、Cから始めよう。void*にはなんでもキャストできるし、元の型に戻すこともできる。まあany。問題は変なことをやった場合。（Cはよくわからないから誰かが例を書いてくれ。） キャストによって変な型が得られた場合の挙動は未定義なんだと思う。（知らないから、誰か仕様を調べてくれ。）未定義というのは、コンパイラとか計算機は何をしても良いという意味で、 プロセスの実行を止める 最適化によってコードが消える プロセスのメモリを破壊しながら動き続ける 鼻から悪魔が出る などのパターンがありうる。実際には大体SEGVで落ちると思うんだけど、それは仕様には含まれていない。 ここで「安全である」というのは「プログラムの実行中に未定義の状態にならない」という意味である。つまり、Cは安全ではない。 キャストの検査で安全になったもの - dynam
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
私と型システムとポエム
最近巷では俄に型システムについての言及が増え、型システムポエマーが増えてる気がするので自分もその時流に乗りたい。 完全にポエムだけどなんかあったら随時指摘ください。直します。 TL;DR 言いたいことはまとめると次 型システムは程度問題なのでちょうどいいところを探すべき 型は万能でも強さが正義でもない(だから未だに研究されてる) よく知りもしないくせに計算機科学を侮辱するのはやめろ 予防線 あくまでポエムですので中身はないです 私は型理論専攻で学位はとったものの研究者ではないのであまり信用しすぎないように 型システムの過去 型システムは大まかに次のような利点があるとされてきた(個人的主観) 「異常」なプログラムを検出する仕組み 静的解析による分かりやすいエラーメッセージ 型そのもののドキュメント性 IDEでのcompletionに貢献 最適化に貢献 (数学に正しく裏打ちされたsemanti
await って言う単語
C# 5.0で非同期メソッドが導入されてから、 正式リリースを基準にしても5年以上、 最初の発表からだと7年以上経っています。 で、5年経っても、「なんて読むの」「asyncのaとawaitのaは違う」などなどが「定番ネタ」として定期的に出てくるわけですが。 特に、ECMAScript 2017がasync/awaitを導入したり、 Unity 2017がやっとC#のバージョンを6.0に上げれる感じになってきたり、 5年の断絶を経て去年からasync/awaitに触れる人が増えているようです。 5年も離れたら、世代断絶も起こりますよね… そりゃ、「定番ネタ」が改めて増えもしますよね… ということで、5年くらい前に同じようなことをどこかで書いてるはずなんですけど、改めて。 英単語 えいしんく まず読み方。 async: エイシンク await : アウェイト ってやつ。async の方が「ア
Xamarin 使いが Kotlin のマルチプラットフォーム対応コードを読んだ感想 - Qiita
Kotlin のマルチプラットフォーム対応、アツいですね。 KotlinConf 2017 Keynote レポート | TechBooster JetBrains/kotlinconf-app: KotlinConf Schedule Application 上の kotlinconf-app の対応プラットフォームは、 サーバーサイド（Kotlin for Server-side, Ktor） Webページ(Kotlin/JS, React) Android(Kotlin/JVM) iOS(Kotlin/Native) となっています、すご！ Xamarin と比べてどうよ？ 普段 Xamarin を使用して Android/iOS アプリを開発しているので、クロスプラットフォームアプリ開発技術が増えて嬉しい限り。 しかも Kotlin で書けるのはとてもよいですね。 正直、C# より
XamarinでWindows / Mac OSX 両対応のデスクトップアプリを作る - Qiita
私はSSHクライアントPoderosaを開発・販売していますが、最近、従来のWindows版に加えてMac OSX版をXamarinを使って作成するという仕事をしましたので、そこでの知見をまとめておこうと思います。 Windows/OSXの両対応アプリを作る際の定石のようなものも見えてきました。 なおこの記事執筆時点ではOSX版Poderosaは開発終盤ですが未公開です。2017年4月に正式リリース予定です。 基礎知識おさらい Xamarin社は、源流はオープンソースの.NET環境ですが、現在はマイクロソフト傘下になっています。Xamarinの構成要素も多岐にわたり、C#コンパイラ、CLRランタイム、本家.NET互換の基本ライブラリ群、Xamarin FormsというiOS/android両対応のモバイルアプリを作る環境、Xamarin StudioというIDE、などいろいろありますが、こ
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回（前編）はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake（10億ドル規模の損失をもたらす過ち）と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問
それでenumとclassのどっちにすれば良いの？ - soutaroブログ
SwiftのenumがObjective Cで欲しいときはどうするか - soutaroブログ この記事には enumが便利なのは ある状態では有効だけど、別の状態では有効ではない値を定義するとき です。 と書きましたが、「それはサブクラスっていうやつではないか」という声があります（どこに？）。その通りで、enumとクラスはよく似ている側面があって、enumでできることはクラスでも（再コンパイルの量とか、網羅性の検査とか、isKindOf:とか、キャストとかの問題を見なかったことにすれば）できるという話でした。 ここで疑問になるのは、 なぜSwiftにはenumとclassという似たような機能が二つ用意されているのか（TMTOWTDI？） 何を考えてenumとclassを使い分ければ良いのか でしょう。 enumとclassの違い Swift的には「classは状態を持てるがenumは持て
ここ最近読んだ技術書籍感想文。 - なるようになるかも
雑多に読んでます。 リンクは書籍の公式サイトです。 黒帯エンジニアが教えるプロの技術 Android開発の教科書 SBクリエイティブ:黒帯エンジニアが教えるプロの技術 Android開発の教科書 （ヤフー黒帯シリーズ） 幅広いトピックを扱っているのだけれど、それゆえにどこかで読んだ本の内容を簡略化しているだけの章もあったり、開発以外のトピックの割合が多かったり、Andorid 開発の高度な技術トピックを期待すると中途半端かもしれないという感想でした。 同時期により初心者向けと思われる「基本からしっかり身につくAndroidアプリ開発入門 Android Studio 2.x対応」という本も出版されていたので、こちらのトピックでよかったんじゃない？という内容もちらほら。 また、アプリのグロース関連の章については、Firebase の登場で大きく変わった部分が多く、タイミングの悪い感じです。
re:僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - ぐるぐる～
元ネタ: 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記 OOPの文脈で見ると、元の記事が言っていることもわからなくはないのですが、対象が広すぎていろいろと不正確になってしまっているので、ちょっとまとめてみます。 元の記事が対象にしているのは、Maybe / Optional / Nullableの3つです。 対応する型を持つ言語を見てみると、下記のようになります。 Maybe(Haskell) Optional(Swift/Java) Nullable(C#) これらは、「値がないこと」を表すもの、という見方では同じですが、それぞれ異なる価値観の元に作られています。 Maybe/OptionalとNullable これらはすべて型パラメータを取ります*1。 しかし、この中でNullableだけは型パラメータに
Microsoft Corporation
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
Less is more：プログラミング言語設計の進歩史 | POSTD
多くの言語は冗長性を有していますが、これらの機能を省いていくことも言語設計の進歩につながります。 巷には数多くのプログラミング言語があり、新しい言語も継続的に紹介されています。でも新しいものが古いものより優れているかというと、そうとは言えません。なぜなら、何が“優れているか”を判断する明確な尺度は存在しないからです。 それでも過去からの流れを見ていくと、優れた言語を作る1つの方向性は、言語にある冗長性を特定し、それらを持たない新たな言語をデザインすることにあるように思えます。 「完璧とは、それ以上足せない時ではなく、それ以上引けない時に達成される」 – Antoine de Saint Exupéry この投稿では、現在までに知られている言語の冗長的機能を見ていくと共に、恐らく冗長性を有しているだろうと思われる機能についても触れていきます。 自ら墓穴を掘るあらゆる可能性 初めてコンピュータ
C# 6.0で知っておくべき12の新機能
Visual Studio 2015正式版のリリースで利用可能になったC#言語の最新バージョン「6.0」の新機能を解説する。CTP 5→正式版に合わせて改訂。 連載 INDEX 次回 → 「C# 6.0」と呼ばれているC#の最新バージョンは、Visual Studio 2015*1で利用可能になっている。 この最新バージョンでは、「.NET Compiler Platform」（コード名：“Roslyn”）と呼ばれる新しいコンパイラーが導入されており、静的解析APIの提供など、コンパイラーまわりに大きな変更が行われている。一方、言語機能に目を向けると、async／awaitという大きな機能が追加されたC# 5.0に比べると、一つ一つの新機能自体は小さい。しかし、それらはプログラムをより書きやすくするための機能なので、C#開発者にとってはやはり重要なアップデートとなっている。 そして、これら
C# 7に向けて(2): 性能と信頼性
C# 7の提案のうちいくつかを見た瞬間、思ったのは「C++ 11みたい」でした。 まあ、背景には、年々C#の適用範囲が広がっていること、そして、オープンソース化に伴って今後はさらに広がるであろうことがあります。 ゲーム開発の標準言語と言えばC# その広がった先の1つはゲーム開発でしょう。「ゲーム開発の標準言語と言えばC#」なんていう煽り(わりかしほんとに「煽り」ではあると思う。「話題にならないよりは炎上する方がマシ」くらいの覚悟の上の)もあります。まあ、割かし昔から、ゲーム開発者にもC#好きな人はいて、ゲーム会社の社内ツールなんかはC#で書かれることが結構あったみたいです。しかし、「ゲーム自体を」となると、これは割かし最近の話。「XNAがあったし(震え声)」と小声で主張もしたいところですが、実際のところ、割かし皮肉なことに、「C#でゲーム開発」が注目を浴びるようになったのはUnityのおか
C# Design Notes / デザイン プロセスについて
Roslynプロジェクトで、GitHubへの移行後初の「C# Design Notes」が公開されたみたいです。 https://github.com/dotnet/roslyn/issues/98 「続に言うC# 7」(順調に行けばC# 7になるであろうもの)に関する話題も初お目見え。単に「こんな仕様を考えています」という話出はなくて、仕様決定プロセス自体をもっとオープンにしていく話や、どういうテーマを持って決めていこうとしているのかという話が含まれています。 今出ている「新機能候補」については、どうせ変わるだろうし、さらっと流す感じで。ここでは、どちらかというと、デザイン プロセスとかテーマの話を中心に軽く和訳しておこうかと。 とりあえず、デザイン プロセスに関する話を書いてたら、気が付いたら全訳してた。今日はここまで（C# 7 で取り組むテーマや、具体的な機能案の話は後日）。 以下、
Revenge of the Types: 型の復讐 - Qiita
本稿は Python に型アノテーションを追加するという提案が行われたときに起こった Python コミュニティの議論の後、2014年8月24日 (日) に Armin Ronacher (@mitsuhiko) 氏によって書かれた記事の翻訳です。 Revenge of the Types Revenge of the Types by Armin Ronacher : Python (REDDIT) Revenge of the Types | Hacker News Python 3.5 で導入を検討している型アノテーションについて興味がある方は以下を参考にしてください。 mypy で静的型付け Python プログラミング 私自身、型システムや他言語に明るくないため、一部未訳の部分があったり、勘違いや誤訳もあると思います。そういった誤りを見つけたら編集リクエストを送ってもらえると助か
Martin Fowler's Bliki in Japanese - Junit新インスタンス
http://martinfowler.com/bliki/JunitNewInstance.html JUnit testing framework のあるデザインについて、よく質問を受ける。 テストメソッドを走らせるたびに、新しいオブジェクトができる点についてだ。 blikiへ投稿するに値する内容だと思ったのでここに記す。 （ 念のために言っておくが、JUnitについて何か書くからといって、 その他のテストのやり方が重要じゃないと思っているわけじゃないですから。 有益なテスト方法はたくさんあるわけで、 JUnit やその親戚（xUnit）がいくら便利だからって、 すべてを解決してくれるわけじゃない。 テストについて言及してるblogがいくつかあるから、 そちらを読んでみることをお勧めする （ Brett Pettichord, Brian Marick, James Bach ）。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C# 7への選択型の導入
