先日の決算の後にお会いした人に、 「どうやれば事業が長続きしますか?」 と聞かれたのですが、言うてもそんなに続いてるわけではないので… とは言え、僕が独立してから出会った人で、 独立を辞めて就職した。なんて人も少なくないので、 逆にそういう人を思い出してみてました。 いくつか共通点あるなーって思ったのでその話でも。 新しい技術を勉強しない Web系の仕事をしていると、毎日のように新技術が出てきます。 ただ、逆説的なのですが、それらは「必須」ではないですよね。 だから、極端に言えば「HTMLとCSSが書けます」というだけで、 一部の仕事は滞り無く行うことはできます。 ただ、今のWebデザイナーという職種を行っている人で、 本当にWebデザインだけをしている人というのは一部何じゃないかと思います。 みんな、ライティングなりコーディングなり行っています。 そっちの方が早いのもありますし、単価の変
ありがたいことにまだ色々と反応を頂いています。 animane.hatenablog.com animane.hatenablog.com 斜め上の発想なのは自覚しているので、もう少し真面目に考えてみます。 前の記事でも書きましたが、サーバー側のリソースをあまり使いたくないというところから発想しています。 お金も人も揃っているなら、従来通りの手法がベターと考えています。 ただ、サーバーが数100台の規模で行っているサービスで、用途にあうなら検証してみもいいと思います。 今までサーバー側で行っていた計算処理をクライアントに移せるので、かなりのコスト削減が可能になるかも知れません。 密結合じゃね? これはもうその通りなんですね。 最近のマイクロサービス的な考えからは真逆の考えだと思います。 Web向けには使えない手法なので、APIの提供を考えるとJSONとかの方がいいですね。 もしアプリのみの
animane.hatenablog.com 前回の記事が予想以上に反応を頂いたので、少し補足します。 ユースケース 記事中ではあまり書いていなかったのですが、基本的に参照系のデータが対象になります。 サーバー側で生成しておいたDBをそのまま使う形です。 なので更新系のデータについては別DBに保存してます。 SQLiteのATTACH DATABASEを使えば、異なるDB(別のファイル)でもJOINが使えるので、 CoreDataで作ったSQLiteのファイルも問題なく扱えます。 ただ、DBのサイズが大きくなりすぎると通信に時間が掛かり過ぎるため、 そのような場合は従来通りAPI経由でJSONなりXMLを使う方がよいです。 他にも日本のネットワーク環境を前提にしているので、通信が遅い環境では別の配慮が必要になります。 あと、ブラウザでは残念ながら使えないと思います。 SQLiteのDBをD
軽い気持ちで投稿したら、思わぬ反響を頂いたこの話。 賛否両論で色々な意見を頂きました。 問題点も含めてある程度メリット・デメリットが見えてきたので、最後にまとめてみます。 ブコメ、Twitterで色々と意見を頂いた方々ありがとうございました。 この場を借りてお礼申し上げます。 前回までのおさらい クライアントとサーバー間で何らかのデータの受け渡しをする時に、 よく使われるフォーマットとしてJSONやXMLがあります。 構造がシンプルなテキストで汎用性が高いため、あらゆるプラットフォーム間の差異を吸収するフォーマットとしてメジャーな存在です。 モバイルアプリも例外ではないのですが、JSONなどを使わずにSQLiteのDBファイルを直接渡してやりとりするというのが先日書いた記事です。 SQLiteはクロスプラットフォームな上に1ファイルで完結するので、1つのファイルで様々なプラットフォームから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く