初心者が本当に知りたかったC#入門以前
この記事は「初心者だった時に知りたかったな…」っていう普通のC#入門だと教えてくれないことが書いてあります。 なので入門記事というより、C#初心者にはちょっと難しい内容もあります！ C#の特徴的なところ C#は変化が早い💨 最近は毎年メジャーアップデート 2019: C# 8.0 2020: C# 9.0 2021: C# 10.0 2022: C# 11.0 2023: C# 12.0 新記法、新しい書き方がモリモリ入る しかも新しい書き方の方が便利で性能が良い(ことが多い) 少し前のC#を知ってる人からするともう別物 解説 C#は6.0までゆっくりな変化だったんですが… 7.0から様子が変わって8.0以降は毎年変わるようになりました。 ↓こちらのスライドの7ページから数枚が参考になります！ あんまり変わらないバージョンもありますが、特に大きなところだと, 「null安全」になった (
パッケージ名 (Package names)
The Go Blogの日本語訳を公開しています。修正は https://github.com/ymotongpoo/goblog-ja/ まで。 パッケージ名 Package names By Sameer Ajmani 序文 Goのコードはパッケージの形で整理されています。同一パッケージ内では、どのような識別子（名前）も 参照することが可能ですが、そのパッケージを利用する場合は、パッケージが外部に公開している型、関数、 定数、変数しか参照できません。パッケージの参照元は常に接頭辞としてパッケージ名を付ける必要があります。 例えば、 foo.Bar はインポートしている foo というパッケージ内の Bar という公開された名前を 参照しています。 良いパッケージ名はコードをより良いものにします。パッケージ名は、その中身の文脈を教えてくれ、参照元で 利用しているパッケージの目的と使用方法
よりよいネーミングを目指して / 20171003 #orecon_ios #akibaswift
俺コン Vol.1 / Day. 2 - connpass https://orecon.connpass.com/event/64285/ での発表資料です。 # 参考資料 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) | Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典 |本 | 通販 | Amazon https://www.amazon.co.jp/dp/4873115655 Amazon | 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES) | Martin Fowler, 児玉 公信, 友野 晶夫, 平澤 章, 梅澤 真史 通販 https://www.amazon.co.jp/dp/427405019X
Swift API Design Guidelinesの紹介(Swift 3版) - Qiita
Swift.org - API Design Guidelinesを読みながら日本語で書き起こしてみました。 (全訳では無く、また一部意訳など混ざっています。) API Design Gudelinesということで、例えばアプリ実装の特に画面側のコード書く際にはあまり気にしなくても良い気がするものも少し混ざっている気がしました。 原文に豊富にあるコード例はほとんど省いたので、適宜原文見た方が分かりやすいかと思います。 基本 用途が明確なこと 用途が明確なことは、最も重要なゴール。コードは書かれるより読まれることの方がずっと多い。 明確さは簡潔さより重要 短いコードを追い求め過ぎて、可読性など損なうのは良くない。 ドキュメンテーションコメントを書きましょう すべての定義にはドキュメンテーションコメントを書きましょう。 (訳注: 処理に添えるコメントではなくクラス・メソッド・フィールド定義など
Find Gender From a Name - Accurate Gender Classification API
Something went wrong! Hang in there while we get back on track 🌎 Global 🇦🇫 Afghanistan 🇦🇱 Albania 🇩🇿 Algeria 🇦🇸 American Samoa 🇦🇩 Andorra 🇦🇴 Angola 🇦🇮 Anguilla 🇦🇬 Antigua & Barbuda 🇦🇷 Argentina 🇦🇲 Armenia 🇦🇼 Aruba 🇦🇺 Australia 🇦🇹 Austria 🇦🇿 Azerbaijan 🇧🇸 Bahamas 🇧🇭 Bahrain 🇧🇩 Bangladesh 🇧🇧 Barbados 🇧🇾 Belarus 🇧🇪 Belgium 🇧🇿 Belize 🇧🇯 Benin 🇧🇲 Bermuda
APIデザインにおける七つの大厄介 | POSTD
(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
