Use CNAME to connect RDS instance

ドメイン名を使用した Amazon RDS データベースインスタンスへの接続の開始 – Amazon Route 53

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/routing-to-rds-db.html

LC_CTYPE error when ssh from Mac to Linux

SSH from Mac to Linux:

macmini:~ congvc$ ssh dev
Last login: Fri Aug 12 16:29:17 2016 from 125.234.96.138
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
[20160814 18:35:26 ec2-user@dev:~ ] $ echo $LC_CTYPE
UTF-8
[20160814 18:39:27 ec2-user@dev:~ ] $ logout
Connection to dev.ace-ltd.net closed.
macmini:~ congvc$ sudo vim /etc/ssh/ssh_config

Comment out the following line:

# SendEnv LANG LC_*

then no more errors.

Public bookmarks 01/21/2014 (a.m.)

• textmate/textmate

  • git clone https://github.com/textmate/textmate.git cd textmate git submodule update –init ./configure && ninja

• About Gradleware | Gradleware

  • Gradleware is a technical service and support company focused on the streamlining of enterprise software automation and helping companies accelerate their time to market.

• READMEのテキストをBitbucketのSourceタブに表示する – Bitbucket ドキュメンテーション – Atlassian Japan Confluence

  • あなたのリポジトリにREADMEファイルがある場合、Bitbucketは Source タブの下のファイルリストにREADMEファイルを表示します。今のところ、Bitbucketは Markdown 形式、 ReStructuredText 形式、そして plain text のREADMEファイルを解釈・表示できます。

      

    異なる拡張子を持つ複数のREADMEファイルがあった場合、以下の順番で表示します。

      

     
    1. README.rst

     

    2. README.markdown

     

    3. README.txt

     

    4. README

     

       

    そのファイルが README.txt であれば、ReStrucutedText形式やMarkdown形式のプリアンブルが記載されていても常にplain textで表示されます。

      

• 【OS X Mavericks】新機能 Finderタブ を使い倒す！ : C-through the Mac

• OS X Mavericks のFinderで、『常にタブで開く』設定が見つからずがっかり･･･。 | マーベリックWEBメディア部

Posted from Diigo. The rest of my favorite links are here.

Public bookmarks 01/20/2014 (p.m.)

• Plugins – Jenkins – Jenkins Wiki

  tags: android continuous integration Jenkins

• Getting started: Building Android apps with Jenkins CI · makinacorpus/android-archetypes Wiki

  tags: android continuous integration Jenkins teamcity

• Gradle Build Android Project “Could not resolve all dependencies” error (But I think I’ve done everything well) – Stack Overflow

  • android update sdk —no–ui —filter platform–tools,build–tools–19.0.1,android–19,extra–android–support,extra–android–m2repository,extra–google–m2repository

Posted from Diigo. The rest of my favorite links are here.

Public bookmarks 01/17/2014 (p.m.)

• Expanding the Storage Space of a Volume – Amazon Elastic Compute Cloud

  • Use the file system-specific command to resize the file system to the new size of the  volume. For a Linux ext2, ext3, or  ext4 file system, use the following command, substituting the device  name that you want to extend.

    [ec2-user ~]$ sudo resize2fs /dev/xvda1

• Restoring TeamCity Data from Backup – TeamCity 8.x Documentation – Confluence

  tags: teamcity continuous integration

Posted from Diigo. The rest of my favorite links are here.

Public bookmarks 01/17/2014 (a.m.)

• IntelliJ IDEA and Android Studio FAQ | JetBrains IntelliJ IDEA Blog

  • If I’m already a user of IntelliJ IDEA, do I need to switch to Android Studio for Android development?

     

    No. Android Studio is focused specifically on Android development and provides streamlined environment and project setup, but otherwise all of its features are available in IntelliJ IDEA.

  • IntelliJ IDEA Community Edition is completely free and open-source, licensed under the Apache 2 license and can be used for any kind of development. Android Studio has the same licensing terms.

• Unchecked Exceptions — The Controversy (The Java™ Tutorials > Essential Classes > Exceptions)

  • One case where it is common practice to throw a RuntimeException is when the user calls a method incorrectly. For example, a method can check if one of its arguments is incorrectly null. If an argument is null, the method might throw a NullPointerException, which is an unchecked exception.

• How to Design a good API and Why it Matters

  tags: api design java

• Java API Design Guidelines

  tags: api design java

  • • An excellent tutorial on netbeans.org, How to Design a (module) API. 
    • A related NetBeans BOF at JavaOne 2005 by Tim Boudreau  and Jaroslav Tulach,  entitled  How to write APIs that will stand the test of time. 
    • Of course, Josh Bloch’s   Effective Java book.
  • The best approach is to say that once something is in the API it will stay there and it will continue to  work. Tweaking the API incompatibly between revisions will result in user reactions ranging from annoyance to  murderous rage. The problem is particularly severe if your API ends up being used by different modules that are  part of the same application. If Module 1 uses Commons Banana 1.0 and Module 2 uses Commons Banana 2.0 then life  will be a whole lot easier if 2.0 is completely compatible with 1.0. Otherwise your users risk wasting huge  amounts of time tweaking classpaths in a futile endeavour to make things work. They might end up having to play  mind-destroying games with  class-loaders, which is a clear signal that you have failed.

  • Be minimalist

      

    Because of the compatibility requirement, it’s much easier to put things in than to take them out. So  don’t add anything to the API that you’re not sure you need.

      

    There’s an approach to API design which you see depressingly often. Think of everything a user could possibly  want to do with the API and add a method for it. Toss in protected methods so users can subclass to tweak every  aspect of your implementation. Why is this bad?

      

     

    • The more stuff there is in the API, the harder it is to learn. Which classes and methods are the  important ones? Which of the five different ways to do what I need is the best?

        

      The situation is exacerbated by the Javadoc tool, which dumps all the classes in a package, and all the  methods in a class, in an undifferentiated lump. We can expect that JSR 260 will update the Javadoc tool to allow you to produce  “views” of the API, and in that case fatter APIs will not be so overwhelming.

        

    • The bigger the API, the more things can go wrong. The implementation isn’t going to be perfect, but  the same investment in coding and testing will yield better results for a smaller API.

        

    • If your API has more methods than it needs, then it’s taking up more space than it needs.

       

      

    The right approach is to base the API on example code. Think of problems a user might want to solve with  the API. Add just enough classes and methods to solve those problems. Code the solutions. Remove anything  from the API that your examples don’t need. This allows you to check that the API is useful. As a happy  side-effect, it gives you some basic tests. And you can (and should) share the examples with your users.

  • Callbacks. If the interface is intended to be implemented by user code, then it is often more  appropriate than an abstract class.

  • The Java language has fairly limited ways of controlling the visibility of classes and methods. In particular,  if a class or method is visible outside its package, then it is visible to all code in all packages. This means  that if you define your API in several packages, you have to be careful to avoid being forced to make things public  just so that code in other packages in the API can access them.

      

    The simplest solution to avoid this is to put your whole API in one package. For an API with fewer than  about 30 public classes this is usually the best approach.

      

  • A good convention for private packages is to put internal in the name. So the Banana API might have  public packages com.example.banana and com.example.banana.peel plus private packages  com.example.banana.internal and com.example.banana.internal.peel.

      

Posted from Diigo. The rest of my favorite links are here.

Public bookmarks 01/15/2014 (a.m.)

• 人気のモバイルサービスが新しくなって登場！「OCN モバイル ONE」 ｜ OCN

Posted from Diigo. The rest of my favorite links are here.