タグ

2015年1月24日のブックマーク (8件)

  • Twitterツールの開発の依頼/外注|その他(システム開発)の仕事 [ID:211997]

    前提:TwitterAPI認証を通さずに利用できること Twitterマーケティングを行っており、下記のようなツールの開発ができればと考えております。 デスクトップアプリケーションでもブラウザ上のアプリケーションでも 実現できればどちらでも構いません!! ※デスクトップアプリケーションの場合はWin、Mac対応 ※ブラウザの場合はchromeのみで大丈夫です! 開発言語は特に指定はございません! _____________________________________________ 【必要機能】 アカウントマスター機能 (ユーザー管理画面 ユーザーへログパス共有) ◆自動Bot作成機能 (アカウントを指定するとそのアカウントのツイートを吸出し、つぶやきをする。) (複数のアカウントをチェックできるようにする) (アカウントを複数指定しその複数アカウントのツイートを吸い出してBOT化)

    Twitterツールの開発の依頼/外注|その他(システム開発)の仕事 [ID:211997]
  • インタフェースと抽象クラスどっち使ったらいいんだ? - Qiita

    どういうケースでどちらを使うかとか知りたかった。 まず結論からいうと多様な議論があるようだった。 だからこれを読んだかたは鵜呑みにせずにいっしょに考えてもらいたい。 結論、インタフェースって? クラスの型(仕様)を定義するもの。 カプセル化と多態性を要求する意味あいが強い。 結論、抽象クラスって? 継承関係をもつ実装の再利用をできる。 継承と多態性を要求する意味あいが強い。 インタフェースとは インタフェースのメンバ変数は必ず定数。自動でfinal public staticとなる。 抽象メソッドのみ記述可能。自動でpublic abstractとなる。 実装クラスは、全ての抽象メソッドを実装する必要ある 多重継承できる。ミックスインというらしい。 多重継承できるけど、メンバ変数は一意でなければならん メソッドの場合は実装をもたないのでダブってても競合せず問題なし 実装クラスはアップキ

    インタフェースと抽象クラスどっち使ったらいいんだ? - Qiita
  • GET /@:id みたいなURLで他との衝突を避ける - Qiita

    Webアプリのルーティングにおいて、各ユーザの個別ページを特殊なものにしたい場合にどういうURLにすると便利かという話に触れる。例えばr7kamuraというIDのユーザ用のページは、Twitterだと https://twitter.com/r7kamura で、GitHubだと https://github.com/r7kamura というURLになっている。 GET /:id だと他のパターンと衝突してしまう もしユーザページに GET /:id というパターンを採用すると、他のURLのパターンと競合してしまうという問題がある。どんなときに困るかと言うと、例えば https://twitter.com/about でTwitterというサービスについて説明するWebページを提供しようとすると、aboutというIDを持ったユーザ用のページが提供できなくなってしまう。 この問題に対してよく

    GET /@:id みたいなURLで他との衝突を避ける - Qiita
  • Swiftを使ってみて直面した闇。現時点で現場でSwiftを採用すべきかどうかの判断材料 - Qiita

    by @mixiappwchr swiftがでてしばらく経ち、実際の現場でswiftを使うかどうか検討されているところもおおいでしょう。 まだ出たばかりなので、当に現場でつかっても大丈夫かどうか悩んでいる人もいるかもしれませんので、実際に現場で直面したはまりどころを共有したいと思います。 ビルドが遅い ビルドに関してはSwiftだと遅くなりました。Androidに比べてビルドが早い点が良かったんですが今後に期待。これをダシに新しいMacを買おうと思います! リファクタリングができない これは地味にきついです。クラス名をやっぱりこっちにしたい!とかアプリを作り始めとかちょいちょいあるのですが、いちいち手で治すという。。 プロジェクトが長期化したら目に見えて厳しいので早めに対応していただきたいところ。 Swift CompilerのOptimize のbug これは結構こわいです。 実装終わ

    Swiftを使ってみて直面した闇。現時点で現場でSwiftを採用すべきかどうかの判断材料 - Qiita
  • 「艦これ」ではなく、「艦これの人気」が好きだった人

    艦これのアニメが盛大にコケた。 たった3話で何が分かるんだ、と思うかも知れないがあの出来からしてこれから盛り返す事はないだろう。もう方向性が決まってしまった。 シリアスだから、日常モノだから、二次創作に媚びたから、とかそういう問題ではなく、単純にアニメとしてつまらなかった、出来が悪かった。もっと根的な問題なのだ。 作画自体は決して悪くなかった(制作会社が4掛け持ちなのにも関わらず)。映像化を前提としていないゲームの世界観を無理矢理アニメ化した結果、全編を通してシュールな空気が漂っている。既存ユーザーすらこう感じたのだから、艦これに触れたことのない人々はほぼ意味不明だったと思う。そういった違和感をいかに上手くごまかすか、そういった所がアニメ制作者の腕の見せ所だったはずだ。しかしそれは失敗し、評価は散々である。 対照的にモバマスのアニメは非常に出来が良かった。それにより絵描きの移動が起き始

    「艦これ」ではなく、「艦これの人気」が好きだった人
  • Google、Android 4.3以下のWebView問題について声明を発表 | juggly.cn

    GoogleAndroid 4.3(Jelly Bean)以下の WebView コンポーネントをアップデートしないと伝えられていた件で、GoogleAdrian Ludwig 氏が自身の Google+ ページでその真相や経緯を公表しました。 WebView は、Android アプリが独自のレンダリングエンジンを実装することなく WEB ページを表示できる機能のことです。Android 4.3 まではオープンソースの WebKit をベースにしていましたが、Android 4.4 で Google 主導で開発・メンテナンスされている Chromium ベースに変わり、Android 5.0 でシステムから切り離され Google Play ストアを通じてアップデートされるようになりました。 同氏は投稿の中で、Jelly Bean に統合されている Webkit のブランチ

  • 卒論が消えた人たち

    バケツ @696_loclock うおおおおおおおおおおおお 卒論少し進めてよっしゃ!ってなってたらデータ消えたうおおおおおおおおおおおお どこにも微塵も残ってねぇぇえええええええええうおおおおおおおおおおおお 2015-01-19 13:10:55

    卒論が消えた人たち
  • The Next Step for Reactive Android Programming

    The next generation of RxJava is out; RxJava 2. If you are working on a project which currently uses RxJava 1, you now have the option to migrate to the new version. But should you immediately start migrating or should you wait and pick up something from your project’s backlog instead? To make a decision, you need to think in terms of Return on Investment (ROI); if the time spent on porting will p

    The Next Step for Reactive Android Programming