Enigmaの実装 - Qiita
先日以下のような tweetを目にしました。 ナチスの暗号機Enigmaがブカレストの蚤の市で100ユーロで売られていた！ https://t.co/CuEWvUINC0 この貴重な歴史の遺物が他にもルーマニア国内に存在している可能性を示唆。発見したコレクターはすぐさま購入しネットオークションで4.5万ユーロで売却。 pic.twitter.com/I5HfVbkXpW — Spica (@Kelangdbn) 2017年7月12日 エニグマは第二次世界大戦中ナチス軍が発明し使用された最強の、”unbreakable”な暗号機です。 エニグマの動作 エニグマは以下の部品から構成されます。 5つのロータ(海軍は8つ) リフレクター 10のプラグを設置するプラグボート AからZそれぞれの入力スイッチ AからZそれぞれの出力ランプ 毎朝コードブックを確認し、その日の 使用するロータ3つとその順番
Swift 3からのアクセスコントロール - Qiita
Swift 3でクラスやメソッドにつける public や private などのアクセスコントロールが見直されました。新しいキーワードが増えただけでなく、これまでのキーワードの意味も変わったので、何がどう変わったのか、それらをどう使い分けていくのかというところを自分なりにまとめました。 これまでのアクセスコントロール Swift 2までは次の3つのアクセスレベルがありました。何もつけなければ internal が指定されたことになります。 public: 同じモジュール内だけでなく、別のモジュールからでもアクセスできる internal: 同じモジュール内からのみアクセスできる private: 同じソースファイル内からのみアクセスできる Swift 3からは次の5つのアクセスレベルになります。何も付けなければ internal になる点はこれまでと同じです。 open: 同じモジュール
Swift オープンソースプロジェクトの Pull Request から Swift 3.0 の命名規約を見てみる - Qiita
今年秋？公開予定で現在まだ絶賛開発中の Swift 3.0 ですが、GitHub のレポジトリには昨日 Swift 3.0 API Guidelines に沿ってソースコードを修正したコミットの Pull Request が承認されました。これで 3.0 が正式に公開されたら間違い無く大半のプロジェクトはまた地獄のようなソースコード改修が余儀無く必要になってくるが、せっかくなのでその前にこの修正コミットの内容を見てみて、これからのソースコードはどういう風に修正されることになりそうなのか、心の準備も進めてみたいと思います。 まあ Standard Library 全体の修正だから修正箇所があまりにも多すぎるので全部見るのに時間がかかるからとりあえずスクロールして気になったところをピックアップしてみたいと思います。 まず第一の感想として、命名規約の冗長性がある程度改善されるようですね。まあこれ
スピーカーが体験した「try! Swift」（準備編） - Qiita
先日、世界最大級（多分）の Swift カンファレンス try! Swift で発表してきました（スライドはこちら）。 過去に（まったく別の技術の）勉強会で発表したことはありましたが、 スピーカー 33 人中 26 人が海外から参加 参加者 536 人中 147 人が海外から参加 発表および 90 分の Q&A セッションは英→日および日→英の通訳付き スピーカー向けの連絡は英語（参加者向けは日英併記） 海外勢 & スピーカーだけで行われた International Reception 参加費 $350 （スピーカーは当然無料です） と、何から何まで 勉強会とはまったく異なる未知の体験 でした。個人的には、 初めて英語で発表した（持ち時間 25 分） というのも大きなチャレンジでした。 東京で行われるにも関わらず、参加費がドル建てだったり、このような行動規範が用意されていたりといったとこ
Dependency Injection with the Cake Pattern in Swift | Acqui-hire Me!
Dependency injection can be a useful tool for creating modular, loosely coupled, and easily testable code. At its core, it’s a simple concept. Objects should have their dependencies passed to them instead of creating their own internally. Unfortunately, simple practices like constructor or property injection can become more difficult and error prone as applications grow larger. Anyone who has done
ごちうさが何期まで続くか、Swiftコンパイラに聞いてみた - Qiita
import XCTest @testable import gochiusa class gochiusaTests: XCTestCase { func ご注文はうさぎですか？() { let _: ご注文はうさぎですか? = ご注文はうさぎですか() } } func ご注文はうさぎですか？2期() { let _: ご注文はうさぎですか?? = ご注文はうさぎですか() } func ご注文はうさぎですか？3期() { let _: ご注文はうさぎですか??? = ご注文はうさぎですか() } func ご注文はうさぎですか？4期() { let _: ご注文はうさぎですか???? = ご注文はうさぎですか() } func ご注文はうさぎですか？5期() { let _: ご注文はうさぎですか????? = ご注文はうさぎですか() } func ご注文はうさぎですか？6期()
SwiftのToll-Free Bridgeの実装を読む - Qiita
Toll-Free Bridgeとは Objective-CにはToll-Free Bridgeという仕組みがありました。 これは、C言語のライブラリであるCoreFoundationと、 Objective-CのライブラリであるFoundationの間で、 対応するクラス同士でバイナリ互換性があり、 ポインタを強制キャストすることでどちらにもなる、という不思議なものです。 下記にNSDataをCFDataとして扱うサンプルを示します。 // コンパイル: clang -framework Foundation a.m #import <Foundation/Foundation.h> int main(int argc, char * argv[]) { @autoreleasepool { NSData * data = [[NSData alloc] initWithBytes: "
Swiftのコンパイラを改造して独自構文を追加する - Qiita
去る 12 月 3 日、ついに Swift がオープンソースになりました！！ 僕は、今度 try! Swift で Swift について話す予定なんですが、 Swift がオープンソースになったからには、コンパイラの中身まで見て証拠を掴んだ上で話さなければならないこともあります。 そんなわけで早速コンパイラのソースを読もうと思ったんですが、目的なく漫然と読むのも辛いです。そこで、勉強がてら Swift のコンパイラを改造して前からほしいと思っていた構文を追加してみました（ リポジトリはこちら ）。 改造の内容は次の二つです。 標準ライブラリに Either<L, R> という型を追加 Either<L, R> のシンタックスシュガー L|R を追加 これによって、次のようなコードが書けるようになりました。 // Int|String は Either<Int, String> のシンタック
socket.io(SIOSocket)をネタにJavascriptCoreに入門してみる with Swift - Qiita
こんなふうに書けていました。 こういうのを、少しの労力で作れるなら、javascript界(以後jsと書きます)の膨大な資産をios界でも気軽に使いまわせるのでは？と思い興味を持っていました。 ということで、今回はこのSIOSocketをSwiftで換装してみて、時が来たら同様のことができるように前知識を蓄えておこう、というコンテンツになります。 JavaScriptCoreについて 今回のようにjsのコードをベースにしたswiftクライアントを作る上で欠かせないのがJavaScriptCore.framework。 これは端的に言うと、JavascriptとObjective-C(Swift)をブリッジしてくれるObjective-C APIです。2013年からあって、Mac/iOS両方で使えます。 ※ 元々Objective-CのAPIなので、Swiftでは使いにくい部分がままあります
Objective-CはSwiftに置き換わるのか？ - Qiita
「Objective-CがSwiftに置き換わる」っていうのがピンとこないのです。 それは、Swiftそのものがオープンソースになっても、あまり変わらないと思います。 以下はすごーくざっくりした知識で書いています。 Objective-Cの歴史 そもそもObjective-Cが何なのか、あまり知られていない気がします。 超ざっくり説明すると、AppleをやめたジョブズがApple OSの「次」として、当時としては革新的なオブジェクト指向OSだったNeXTSTEPを生み出しました。NeXTSTEPの存在は後の様々なOSに影響を与えました。OSXやiOS自体、NeXTSTEPの系譜です。 NeXTSTEPはオブジェクト指向のOS・開発環境・開発言語を統合し高い生産性を実現していました。その開発言語がObjective-Cでした。NSのプレフィクスの意味が、NeXTSTEPの略称というのは、比較
Swift 2.0 の try, catch ファーストインプレッション - Qiita
WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。本投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている（検査例外のような形） try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md