はてなブックマーク

※本記事は弊社が技術書典 13 で無料配布する同人誌「ゆめみ大技林 '22」の寄稿です。追筆や訂正等がある場合はこの記事で告知します。 意外かもしれませんが、Swift はアップルの手によって生み出されるも、アップルのエコシステムだけしか使えないわけではありません。Swift は汎用プログラミング言語です。その汎用さの証拠として、アップルと全く関係ないサーバサイドでも使えるわけです。 サーバサイド Swift と聞くと、アンテナ貼ってる人なら Vapor は一度は聞いたことあるかもしれません。他にも Kitura や Perfect、そして smoke-framework など、実は Swift のサーバ向けフレームワークがいくつもあります。「よしこれからサーバサイド　Swift をやってみよう」と思い立ったら、これらのフレームワークをとりあえず落としてみる人も多いでしょう。 ところがそれ

背景 ここ数年間は、筆者が採用周りの仕事も増えてきて、そしてカジュアル面談などでも特に学生さんを中心に「就職するために必要なスキルやレベルを教えてほしい」とか、「自分のスキルが会社の開発業務でも通用するかわからない」的なご相談を多くいただいております。 確かに学生のうちは、企業での長期アルバイト経験がある方を除いて、ほとんどの人は社会人経験が皆無と言っていいでしょう。そんな中で不安を覚えるのも無理はありません。というわけで少しでも企業でのエンジニアとしての働き方のイメージが明確になれたらと思いながら、この記事を綴らせていただきました。 免責事項 この記事の内容については、あくまで筆者の経験に基づいた話であって、全ての企業に通用するわけではありません。ただ大きくかけ離れたことはおそらくないと思います。 本文 学生のうち、特に情報工学の経験がなく、あくまで趣味駆動でプログラミングを始めた学生さ

免責事項 本記事で扱っているのはあくまでかなり極端的なケースであって、普段の開発ではそこまで神経質になる必要はないと思います；そのため「こう言うこともあるね」とどこか頭の中に入れて、実際このようなバグが発生したとき思い出していただければと思いますので「小ネタ」として書かせていただきます。 うわっ…私の平均値、膨らみすぎ…？ 安心してください、私は別にこの記事で平均値と中央値の違いとかみたいなセコいことを言うつもりはありません、あくまで我々が日常で使ってる「平均値」のことです。$(x + y) \div 2$ のことです。 ところで上記の数式の通り、我々は平均値の定義1を、二つの数字を足して 2 で割る、という風に教わったはずかと思います。そのため我々は基本このように平均値メソッドを書くことがほとんどかと思いますね。筆者は iOS エンジニアなので、ここは Swift のプログラム2を書きま

本記事はこの記事の日本語訳です。翻訳許可をいただいております。 以下翻訳： もし Cocoa 開発やソフトウェアビジネスのブートストラップについての最新の記事を常にキャッチアップしたいなら、ぜひ Twitter で私をフォローするかメールリストを購読してください。 開発者として、パフォーマンスの良さは我々のユーザにワクワクと嬉しさを与えるのに評価しきれないほど貴重なものです。iOS ユーザの目は非常に高く、そのためもしあなたのアプリが動作がモサモサしたり、すぐにメモリプレッシャーでクラッシュしたりすると、彼らはあなたのアプリを削除するか、最悪悪いレビューまで残してしまうでしょう。 私はアップルに 6 年間を在籍し、その歳月を Cocoa フレームワークやファーストパーティーのアプリに費やしてきましいた。私が手掛けたものには Spotlight、iCloud、app extensions、そ

明けましておめでとうございます。新しい年ということでアイコンも一新した lovee です。はい、あまりにもビビったのでラノベっぽいタイトルにしてみました。後悔はしていない。 なぜアプリ作ろうと思ったの？ いやーそれなりに長い間 iOS エンジニアやってきたけど、業務ではそれなりにたくさんのアプリを作ってきたけど、完全に個人でアプリを作ったことがまだ全くないんですよね。というわけで去年「今年中に個人アプリを出す」という目標を立てました。結局去年中には出せなかったがとりあえずまだ今年度中ということで開き直ってます どんなアプリ？ 簡単に言うとただ単にユーザが入力した文字列を QR コードに変換するだけのアプリです。それだけです。でも本当の使い方はアプリをいちいち立ち上げて QR コードを作るのではありません。このアプリは iOS ネイティブの共有メニューを対応しているので、別のアプリから共有メ

2021-10-17 追加 弊社の Android 採用課題も公開されましたので、そのリンクを追加しました。 2020-05-18 追加 本日から弊社の採用課題がこちらに変更されました。これまではアプリをゼロから作成していただく課題でしたが、今後は既存のコードをリファクタリングしてもらう課題となりました。ただし我々が確認する項目はそれほど大きく変更するわけではありませんので、本記事の内容の多くは引き続き有効です。 ここ数ヶ月は、iOS のエンジニア採用のコードチェックにもよく参加していますので、そろそろ良さそうと思って、ここで私がコードチェックする時に一体何をチェックしているのかを共有し、皆さんの転職活動やキャリア設計に役に立てればと思います。 Disclaimer この記事の内容はあくまで株式会社ゆめみの iOS エンジニア採用のものです。弊社以外の iOS エンジニア採用や、弊社でも

前書き 本記事は受託開発前提で書いております。そのため、受託開発における特殊な要件がいくつかあります。もちろん通常の開発にも通用する部分は多いですが、どこまで流用するかは読者の皆さん自身にご判断をゆだねます。 本記事のサンプルとして使われたプロジェクトのバイナリデプロイ1はこちらの GitHub リリースページ から確認できます。 本記事は下編：Bitrise 編で、CI 運用について説明します。Xcode プロジェクトの作成については上編をご覧ください。 要件 基本開発環境は Xcode を利用します。 基本 CI/CD 環境は Bitrise を利用します。なお本記事も Bitrise アカウントを所有している前提で書かれており、登録についての説明は割愛します。 動作環境は社内開発環境（Development）、納品先検証環境（Staging）と本番環境（Production）の三つが

前書き 本記事は受託開発前提で書いております。そのため、受託開発における特殊な要件がいくつかあります。もちろん通常の開発にも通用する部分は多いですが、どこまで流用するかは読者の皆さん自身にご判断をゆだねます。 本記事のサンプルとして使われたプロジェクトはこちらの GitHub リポジトリーからダウンロードできます。 本記事は上編：Xcode 編で、プロジェクトの作成を説明します。CI 運用については下編をご覧ください。 要件 基本開発環境は Xcode を利用します。 ライブラリーの管理は Carthage を優先に利用し、Carthage で対応できないものは CocoaPods を利用します。 開発ツールの管理は基本 Homebrew を優先に利用し、Homebrew が利用できないものは Bundler や Mint 等を利用します。 動作環境は社内開発環境（Development）

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

※本記事は個人的な考察であり、ゆえに間違った箇所などがございましたらぜひとも反論やマサカリを投げて頂けたら嬉しいです。なお、本記事における「MVVM」は、基本最近お流行りの RxSwift のデータバインディング機構に依存した、UIViewController に ViewModel を保持する MVVM を指します。 ここ数年、少なくとも日本では iOS 開発において、MVVM が非常に流行っているようです。少なくとも、いろんな勉強会やカンファレンスに参加したときに MVVM の話はよく聞きますし、筆者自身としても個人プロジェクトを除く、本業副業両方とも担当しているプロジェクトは基本設計として MVVM を採用しています。 しかし、かといって MVVM は MVC と比べる際、圧倒的な優位性を持っているのかといえば、少なくとも筆者はそう思いません。もちろん MVC と比べた MVVM の

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 晒すつもりではありませんが、Facebook で友人のとある投稿を見かけて最初は「三単現にしないと💢」という軽い気持ちで返答したのですが、よくよく考えて見たらこれ思った以上のクソ命名でしたので、とりあえず流れのスクショを上げときます： はい、今回の記事はマサカリです。あしからず。 見ての通り、最初は友人の後輩ちゃんが isCanUseSkill という明らかにアレな命名をしてきたので、友人がそれを指摘をするも、まさかの allowSkill という更にダメな名前をつけてきた件。isCanUseSkill はまだ「なんだこいつの英語はｗ

iOS 11 では Safe Area という概念を導入しました。そして本日のイベントをご覧になられた方、もしくは iPhone X を少しでも掘ってみた方ならわかると思いますが、この Safe Area の概念はレイアウトする時、特に iPhone X ではものすごい重要になってきます。 具体的に iPhone X 向けのレイアウト最適化の話については是非とも公式の Building Apps for iPhone X と Designing for iPhone X をご覧いただければと思いますが、ここではとりあえず筆者みたいな Auto Layout 死んでも使わない人（）向けに「Safe Area」をコードで取る方法を簡単に説明したいと思います。（ちなみに Auto Layout でしたら safeAreaLayoutGuide を使うことができます） iOS 11 からは UIV

前書き 何かと最近 iOS 界隈では設計の話が流行ってるようで、乗るしかない、このビッグウェーブに自分が今まで開発してきた経験と今使っている設計を一回整理してまとめるチャンスでもあると思って、この記事を執筆させていただきました。長々と駄文を垂れ流してますがどうか温かい目で見守っていただけると幸いです。 また、あらかじめ断っておきますと、筆者が今使ってる設計は一昨年書いたこの振り返り記事に基づいた MVC モデルから派生したものです。 なぜ未だに MVC 「未だに」という言葉には語弊を感じる方もいるかもしれません、が、最近の iOS 界隈ではやはり Clean Architecture とか VIPER とかの設計がとても話題になっているのも事実なんじゃないかと思います。そうでなくても、MVVM や MVP もじわじわと着実に浸透していると感じております。少なくともハッカソンをいくつか参加し

前書き 皆さんは Nintendo Switch ライフを満喫していらっしゃいますか？筆者は全く満喫できていません。最近散財が多すぎて本体を買えないのです。 それでも一応職業柄で Switch を触ったことならあります。そして触ってみて最大の感想は、やばい右側の Joy-Con がサイズにもボタン配置にも手に持った感覚にもプレゼンリモコンとしては最高だということでした。 購入 というわけで、さすがに本体は買えないが、なんと Joy-Con は片方だけでも販売していると知って、これはもう神様からの「買え」のお告げかと思って買ってきました。 ちなみに買ったのはアキヨドです。Amazon では未だにプレミアがついてるしいつ発送されるかもわからないし、家の近所にあってすぐに買えるアキヨド最強です。もちろん右側のグレーモデルですが。（赤は在庫ないしそもそもプレゼンリモコンとしてはちょっと派手だし）

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前書き 皆さんは「オープンソース」という言葉聞いた時、何を思いますか？「なんかかっこいい」とか、「よく知らないけどとりあえず私には関係なさそう」とか「いつか私もオープンソースプロジェクト作れないかな」とかいろいろあると思いますが、「なんかすごすぎて自分には届かなそう」とか思うのは非常に勿体無いと思います。だってオープンソースは誰にでもできることですから。やることは非常に単純で、ただ単に自分が書いたコードを公開して誰でも自由に入手できるようにするだけです。 まあそんなオープンソースですが、今となってはもはやプログラマにとって切り離せない存

iOS でこのシステムフォントが使いたいとか、そもそもどのフォントが内蔵されてるのか知りたいとか、そんな需要たくさんあると思います。 というわけで、全てのシステム内蔵フォントを引っ張り出して iOS 上で描画する一覧アプリを作りました： https://github.com/el-hoshino/iOSAllFontsDisplayer まあ実現は非常に簡単です、単純に UIFont.familyNames() と UIFont.fontNamesForFamilyName(_:) の二重ループでラベルを作ってスクロールビューに貼り付けるだけです。そこのソースコードを抽出するとこれだけです： override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view,

気づいたらもう僕の担当日になったんですね。Swift 関係の Advent Calendar に空きがないか探すのがまるで昨日の出来事みたいなのに。 と言うか僕そもそも Swift 愛好会に参加してない気がするのですが本当に大丈夫ですかね？えっ？ダメ？仕方ない書くのやめましょうか（おいこら というわけで Swift 愛好会に参加してないはずなのに記事予約しちゃった理由は上記通り、Swift 関係の Advent Calendar の空きを探してたら見つかったのがここだったわけです。どうか温かい目で見守ってください。それがダメなら今から飛び込み入会させてください（笑） でも予約したのはいいものの、正直結局何を書くべきか、全くのノープランです。すみません。最近 Watch Dogs 2 にハマってて。あれやっぱりプログラマなら一度やるべきゲームだと思うんですよ。別にゲーム内でプログラミングする

まだ Storyboard で消耗してるの？——Re:ゼロから始める視覚表現（ビジュアルリプリゼンテーション）XcodeStoryboardAutoLayoutポエムSwift 煽り全開の dis りタイトルになってしまいましたが、まあそれくらい筆者が不満を抱いたってこととして受け止めていただければ幸いでございます。 ほとんどの iOS 開発の教材はおそらくこのように教えているでしょう。「Xcode 開いて、Main.storyboard をクリックして、blabla…」と。 そしてほとんど（筆者調べ）の開発者たちは、結局最後まで、Storyboard の効率的な使い方が見つからず、多少なりとも心のどこかで「F*ck」とぼやいているのではないかと。 というかそもそもそこまでたどり着く前に「Storyboard の使い方わかりましぇーん」で終わってしまう屍も数多くいるのではないかと。 アップ

通常 Swift で protocol を定義した場合、その protocol は class のみならず struct や enum などにも適用できてしまいます。ほとんどの場合これは非常に便利ですが、時々逆に不便になることもあります。例えば Delegate を protocol で定義した際、値型の struct などにも使えるため、var delegate = Delegate? が書けても weak var delegate = Delegate? が書けません。値型に weak がそもそも意味ないからです。もちろん Delegate を struct にするという手もありますが、Delegate の性質上、参照型の方が嬉しいという場面が非常に多いです、例えば MVC アーキテクチャで UIViewController を Model の Delegate にしたいときとかまさに

プロローグ 今日は iOSDC の日でしたが、気付いたらもうチケット完売してて行けなかったorz というわけで iOSDC の場外トーク（嘘）で、「一反田えー」「二反田びー」…「二十六反田ぜっど」「二十七反田えー」…のように定義した場合、果たして「千反田」は「える」になるのだろうか、Swift で検証してみた。 最低限の検証 まずは一番簡単なソースとして、1反田a 2反田b 3反田c…の出力を作ってみる： let alphabets = Array("abcdefghijklmnopqrstuvwxyz".characters) for i in 0 ..< 1000 { let alphabet = alphabets[i % alphabets.count] print("\(i + 1)反田\(alphabet)") } // 最後の行：1000反田l おお、ちゃんと 1000 番目

今年秋？公開予定で現在まだ絶賛開発中の Swift 3.0 ですが、GitHub のレポジトリには昨日 Swift 3.0 API Guidelines に沿ってソースコードを修正したコミットの Pull Request が承認されました。これで 3.0 が正式に公開されたら間違い無く大半のプロジェクトはまた地獄のようなソースコード改修が余儀無く必要になってくるが、せっかくなのでその前にこの修正コミットの内容を見てみて、これからのソースコードはどういう風に修正されることになりそうなのか、心の準備も進めてみたいと思います。 まあ Standard Library 全体の修正だから修正箇所があまりにも多すぎるので全部見るのに時間がかかるからとりあえずスクロールして気になったところをピックアップしてみたいと思います。 まず第一の感想として、命名規約の冗長性がある程度改善されるようですね。まあこれ

let hexString = "FF" var hex:UInt32 = 0x0 let scanner:NSScanner = NSScanner(string: hexString) scanner.scanHexInt(&hex) print(hex) //255 まあ Objective-C の時代ならこの書き方がベストだったのかもしれませんが、せっかく今の Swift はもっと便利な書き方あるのにな… var 使わずに済むし NSScanner 使わずに済むしコード量も半分で済むし（変換だけを考えれば半分どころか 1/3 になるんやで）何より余計な NS オブジェクト作らずに済みますから純正は Swift コードだけで出来ちゃうのがすごい気持ちいいんですよな。さらに radix: の記述で御察しの通り、これは十六進数だけでなくいろんな進数に対応している（正確に言うと hexSt

前書き 自分は別にプログラマではなかったのです。プログラミング経験と言えば中学校の時一時期 BASIC を少し独学して、大学でプログラミング入門の授業で C を少しだけ触って、あとはまあ4年生の時の卒業研究でそれなりに CUDA プログラムを組んだ程度。あとは就職してからディレクターをやりながらも少しくらい（主に UI 周り）既存の Objective-C のソースコードの修正をやった程度です。 そんな僕が会社の都合もあってプログラマにジョブチェンジさせられ、ちょうど Apple も新たに Swift という言語を世に送り出したからこれならまあまあ簡単そうっと思いながら少しずつプログラムを組み始めました。 そしておおよそ1年くらい経ちましたし、そろそろ今までの経験をまとめてみたいと思っております。この記事では Swift の文法についても話しますし、もう少しでっかい規模のデザインパターンな

UIImage の画像は作りやすいです。適当に例えば UIImage(named: "SomeImage.png") で書けばとりあえず iOS や OS X で使う画像データをつくれます。ところが、時には画像そのものでなく。画像の中身のデータ、すなわち画素データを配列で欲しい時もあったりします。例えば画像解析する時とかですね。では、画素データをどうすれば取得できるでしょうか？結構いろいろググってみたけどなかなか最適解が見当たらなかったのですけど、一番手取り早く簡単かつ速い方法ですと下記のような感じですかね func getByteArrayFromImage(imageRef: CGImageRef) -> [UInt8] { let data = CGDataProviderCopyData(CGImageGetDataProvider(imageRef)) let length =

はじめに GPU もしくは GPGPU 開発経験がある方なら恐らくわかると思いますが、GPU 演算において一番のネックは GPU と CPU の間のデータ転送スピードです。そのため、例えば GPGPU 開発でしたら一番重要なポイントは CPU からは必要なデータを GPU に転送してから、なるべく CPU との通信を一切せず、全ての演算を GPU で完結させて必要な結果データのみ CPU に返すことです。描画においても同様で、基本はなるべく必要なデータは全て一度の転送で終わらせて GPU に任せたい演算は GPU 内で完結させることを心がけることが重要だと思います。なのに…なんと iOS の CALayer は filters プロパティをサポートしないと今日はじめて知って絶賛 orz 状態なう。 filters プロパティとは Apple 公式開発資料によりますと、要は CALayer

前言 開発が進むと、一人で複数の案件を担当したりすることも増え、できれば共通の部分を一つにまとめたい、と言った欲求も出てくるのではないかと思います。その時に便利なのが、Framework というやつです。今回は Framework の作り方をとてもやさし〜くお伝えできればと思います。 準備 Xcode でまず Workspace を作ります（1 プロジェクト 1 フレームワークでしたら普通に Project も問題ないのですが、複数のプロジェクトをまとめることを想定しているので敢えて Workspace で作ります）。まあ適当に File > New > Workpsace で作っちゃいましょう 作ったらこの時点では Workpsace は空ですので、左の Project Navigator（まあ左側のサイドバーの事）に右クリックして New Project を作りましょう 今回は iOS

はじめに これは自分用のメモでもありますが、同時にもし「Storyboard 面倒くさい！ソースコードのみで UI 作りたい！」というような方がいらっしゃいましたら、ご参考になれればと思います。 また、ソースコードは GitHub に公開しております。 なぜコードで UI 作るか ぶっちゃけ言いますと自分 Storyboard 使えないだけです。はい。そもそも以前 Interface Builder の時代からまともにそういったツール使ったことなかったし、要素配置とかページ遷移とかもどうやって作ればいいのかわからないし、今まではゲームを作ってきたから iOS 特有の画面遷移とかも特に使ったことなかったし、あとマウスよりもキーボードのほうが速いってのもありますね。まあ要するに自分にとってソースコードのほうが画面配置がわかりやすいです。 実際作ってみる 目標と手段 まあ何事もまずは目標を決める