Use CNAME to connect RDS instance

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


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
-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
[20160814 18:39:27 ec2-user@dev:~ ] $ logout
Connection to 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.)

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


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

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


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

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


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

    • 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.
    • 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.
  • tags: api design java

  • tags: api design java

    • 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.)