はてなブックマーク

はじめに threading を用いた並行処理をさせる常駐型の Python プログラムにおいて、データベースに接続する際に sqlalchemy の create_engine の使い方を間違えるとデータベース接続数が爆増してしまうので注意が必要です。本稿ではそれについて簡単に説明したいと思います。 TL;DR 以下のいずれかの方法を選択すると必要以上に接続数が増えることはないでしょう。 create_engine() はプログラム開始時に一回だけ呼んで Engine クラスインスタンスを使い回す NullPool を指定してコネクションプールを使わないようにし、scoped_session でセッションを生成する 環境 以下の環境で実験しています。 項目名 バージョン

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

シーケンス図をテキストで描いてMarkdownに埋め込みたい README.md のような Markdown ファイルに、シーケンス図をテキストで描いて、埋め込みたいんです。 でも、たいていは「テキストでシーケンス図を描いて、それを画像にしてアップロードして、そのURLをMarkdownに記述する」という方法でした。 Markdownテキストでシーケンス図とフローチャートを描く - Qiita Markdownでシーケンス図を書いてGithubのREADME.mdに埋め込む - Qiita もっと簡単にできないものかと調べてみると、StackOverflow に git - How to integrate UML diagrams into GitLab or GitHub - Stack Overflow がありました。 PlantUML proxy service を使う方法です。

2019-02-20 14:43:09.246 8097-8153/com.example.coroutinenetworkblockingsample D/MainActivity: coroutine#0: start 2019-02-20 14:43:09.251 8097-8154/com.example.coroutinenetworkblockingsample D/MainActivity: coroutine#1: start 2019-02-20 14:43:09.252 8097-8156/com.example.coroutinenetworkblockingsample D/MainActivity: coroutine#2: start 2019-02-20 14:43:09.258 8097-8160/com.example.coroutinenetworkbl

今さら HttpClient を使ってる人なんていないよねー 2018年にもなって平成だって終わろうとしてるのに、未だに HttpClient(Apache HttpClient, DefaultHttpClient, AndroidHttpClient) を使ってる人なんていないと思います。 が、私が 2011 年から開発している とあるアプリ ではまだまだ HttpClient を使っていて、クッキーの処理などでかなりごにょごにょした部分もあり、すぐには移行できない状況でした。 とはいえ、ご存じの通り Playストアの仕様が変わり、2018年8月から新規アプリ、同11月からは既存アプリの更新時にも、targetSdkVersionを API Level 26（Android 8.0）以上にする必要がでてきました。で、サクッと targetSdkVersion=28 (Android 9

概要 Android 7.0以降で TextView に SpannableStringBuilder でフォーマットした文字列を設定する際に、URLSpan と ForegroundColorSpan が混在すると描画が乱れるようです。N Preview1 から発生していたと記憶しています。 上記の例では分かりやすく URLSpan の長さを1文字減らしてるんだけど、「＃２月限りの」だけ色がおかしくなってる。 ForegroundColorSpan が無視されている感じ。 というわけで検証した結果のメモを残しておきます。 検証1 ごくごくシンプルなTextViewで試してみたらこうなった。 下記のコードの通り、なぜか交互に実行すると色がおかしくなる。 3つ目と4つ目は実行する順序を変えただけなんだけどおかしくなる部分が変わった。 この場合、「3組目」で本現象が発生するらしい。 final

結果と雑感 主に赤枠部分が青枠部分に集約されている感じ。 名前が ～～line_text という TextView は複数の要素を Span で結合して集約したもので、実はその効果がほとんど。 LinearLayoutが1つだけ残ったのが悔やまれるけどアプリの仕様上仕方ないし、今後のConstraintLayoutに期待。 (retweet_user_iconとretweet_follow_count_line_textのどちらが大きくなるのかツイートや画面サイズによって不定なのでその下に配置する要素の拘束を指定できない) 正直言ってこれくらいならRelativeLayoutでも十分だった。でもConstraintLayoutの拘束の書き方は好き(align_leftよりもconstraintLeft_toLeftOfのほうが分かりやすくて好き。試行錯誤しやすいし。嫌いという人がいるのもま

2016/05/24 23:00(日本時間)に発表されたTwitterの仕様変更に関するAPIドキュメント Upcoming changes to Tweets | Twitter Developers (2016/5/25 14:00時点のもの ⇒ 随時更新)を抄訳してみました。 原文が長すぎていまいちパッと把握できないので写経した感じです。 正確な情報は必ず 原文 をご確認くださいね。 2016/7/20: API変更点を要約した「概要」が原文に追加されていたので追記しました 2016/9/14: 「最近の改訂」として投稿系の各パラメータやエラーコード(44,385)が原文に追加されていたので追記しました はじめに 本ドキュメントでは人々が140文字でより多くのことを表現できるようにする、つまり、 公開された会話をTwitter上でより簡単にフォローできるようになり、会話を豊かにする

はじめに Realm Advent Calendar 6日目を担当する@takkeです。 私が作成したAndroid用TwitterクライアントTwitPaneで「ツイートを保存するDB」としてRealmを採用してから4ヶ月ほど経ちました。 導入当初に Twitterクライアントの内部DBをSQLiteからRealmに移行したときのノウハウまとめ という記事を書きましたが今回はその続編としてその後の運用で得られたノウハウを書いていきます。 と言いますか・・・、 世間にはRealmの性能や便利な使い方など良い側面ばかり取り上げた記事があふれていますが僕らはもっと現実的なノウハウを求めているんです！！今回はその呼び水として「Realmが原因でクラッシュすることが多すぎたのでSQLiteに自動的に縮退する仕組みを作った」件について書きます。 Realmのバージョンは少し古くて 0.84.1 です

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

pick 8145f1c Fix screen rotation problem pick d90db4a v1.2.4 pick 646bf79 Fix screen rotation problem pick 71a6940 v1.2.4 # Rebase ed7420a..71a6940 onto ed7420a # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this c

これは Realm の Core 部分が NDK で書かれており、全アーキテクチャ用の .so ファイルが含まれているためです。 そこでアーキテクチャ別に APK を用意する(分割する)ことで APK サイズの増加量を 700 KB 程度まで抑えることができました。 公式の情報は Reducing your Android APK size when using native libraries — how we made Realm 76% smaller in your apps - Realm is a mobile database: a replacement for SQLite & Core Data です。 Our distribution package (available on our website under Download->Java) contains a

Twitterクライアントのようなそれなりに大規模なアプリの内部DBをSQLiteからRealmに置き換えるといういわゆる「飛行中の航空機のエンジンを取り替える」系の修正をやってるので現実的で苦々しい知見ばかり貯まっていく — 竹内裕昭 (@takke) August 4, 2015 拙作のAndroid用TwitterクライアントTwitPane の内部DBをSQLiteからRealmに変更しました。 この移行作業にあたって色々とノウハウがあったので備忘録代わりにメモしておきます。 Realmの日本語の情報はまだまだ不足していますので普及の一助になれば。 とはいえ、、開発中に自分がTwitterでつぶやいていたものから拾っていますので真偽不明のものが多いです。以下に書かれていることを鵜呑みにせず、必ずご自分で検証してから導入しましょう。 初めて Realm を使うという方はまず Real

いつもTwitter4Jの機能追加をするたびに試行錯誤することが多いので備忘録代わりにまとめておきます。 前提 AndroidStudio IntelliJ IDEA で Twitter4J の機能追加や調査・修正といった作業をする。 AndroidStudio2.1あたりからmavenがサポートされてないっぽいんで IDEA で。 Windows10 TortoiseGit Forkして最新版を取得する https://github.com/yusuke/twitter4j を Fork する(https://github.com/takke/twitter4j) clone したり色々やって下記の状態。 $ git branch -a * master video_support remotes/origin/HEAD -> origin/master remotes/origin/m

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

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

はじめに レンタルサーバやVPSを借りていると不意にデータが飛ぶことがたまにありますよね。 そんなときに備えて自宅サーバにリモートサーバのデータを差分でバックアップしておけると安心です。 有償/無償/商用も含めて様々なソリューションがあると思いますが、自分はお手軽にrsyncだけで実施しています。 方針 リモートのサーバAから、手元のサーバBにバックアップします。 リモートサーバA(IPアドレスaaa.bbb.ccc.ddd) [cron]リモートサーバA内のバックアップ対象データを /for_backup/ に集める 手元のサーバB [cron]rsyncで A:/for_backup/ を /remote_a_backup/latest に転送する [cron]rsyncで /remote_a_backup/latest を /remote_a_backup/YYYYMMDD に差分バ

2014/10/22 に公開された AppCompat v21 — Material Design for Pre-Lollipop Devices! | Android Developers Blog を翻訳(多少の意訳を含む)してみました。 ちなみに原文の草稿は 10/17 に https://chris.banes.me/2014/10/17/appcompat-v21/ にて公開されており、そのコメント欄でも著者との活発な議論(Q&A)が繰り広げられていたので貴重な情報源です。 あと、この記事で話題にしている appcompat-v7/21 を組み込んだTwitterアプリを公開していますので興味がありましたらどうぞ(宣伝)。 (11/10 追記) http://googledevjp.blogspot.jp/2014/11/appcompat-v21-lollipop.html

... signingConfigs { myConfig } buildTypes { release { runProguard true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-project.txt' signingConfig signingConfigs.myConfig } } applicationVariants.all { variant -> if (variant.buildType.name.equals("release")) { variant.outputs.each { output -> if (output.outputFile != null && output.outputFile.name.endsWith('.apk'))

背景 ActionBarSherlock や Support Library の ActionBarActivity を使えば Android 2.x でも ActionBar 付きの Activity を作れるわけですが、物理メニューキーがある端末ではActionBarに「・・・」(いわゆるthree dots)が表示されません。 Androidのデザインガイドライン的にはこれが正しい振る舞いと思いますし個人的にはそれでかまわないんですが、サポートの手間がものすごくかかる(「もし画面右上に「・・・」ボタンがあればそれを押し、なければ端末のメニューボタンを押して」を毎回説明する)ので常時表示することができればウレシイなと思って調べてみました。 ついでに上記スクリーンショットのように、サブメニューにアイコンを付けられるようになったのでメニュー項目が若干分かりやすくなるというメリットもあります

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