Google Protocol Buffers Helloworld(Java)

Categories: Java; Tagged with: ; @ July 3rd, 2014 0:15

This is a Protocol Buffers hello world project following https://developers.google.com/protocol-buffers/docs/javatutorial

you may find all source code from github: https://github.com/guoliang-dev/google-protocol-buffers-java-helloworld

image

Code Generation

The message definition: addressbook.proto;

D:\dev\tools\protoc-2.5.0-win32>protoc.exe -I=D:\dev\..\src\main\resosurce\ --java_out=D:\dev..\src\main\java  D:\dev\…\resosurce\addressbook.proto

AddressBookProtos.java is the generated Java class;

TestCase:

package com.liguoliang.java.protobuf;

public class ProtocolBuffersTest {
     private static final String name = "google";

    @Test
     public void testBuildInstance() throws Exception {
         Person person = buildNewPerson();
         assertEquals(name, person.getName());
     }

    @Test
     public void testWriteInstanceToFile() throws Exception {
         String path = "./src/test/resources/address.txt";
         AddressBook.Builder addressBookBuilder = AddressBook.newBuilder();
         addressBookBuilder.addPerson(buildNewPerson());
         AddressBook addressBook = addressBookBuilder.build();
         FileOutputStream outputStream = new FileOutputStream(path);
         addressBook.writeTo(outputStream);
         outputStream.close();
         System.out.println("AddressBook write to :\n " + path);
         URL url = Resources.getResource("./address.txt");
         String contentInFile = Resources.toString(url, Charsets.UTF_8);
         assertTrue(contentInFile.contains(name));
     }
     @Test
     public void testParseInstanceFromFile() throws FileNotFoundException, IOException {
         AddressBook.Builder addressBookBuilderRead = AddressBook.newBuilder();
         addressBookBuilderRead.mergeFrom(new FileInputStream("./src/test/resources/address-test.txt"));
         AddressBook addressBookRead = addressBookBuilderRead.build();
         System.out.println("AddressBook loaded: \n" + addressBookRead.toString());
         assertEquals(1, addressBookRead.getPersonCount());
         Person person = addressBookRead.getPerson(0);
         assertEquals(name, person.getName());
     }
     private Person buildNewPerson() {
         Person.Builder personBuilder = Person.newBuilder();
         personBuilder.setId(1);
         personBuilder.setName(name);
         Person person = personBuilder.build();
         return person;
     }

}

How To Design A Good API and Why it Matters 笔记

Categories: Java; Tagged with: ; @ June 2nd, 2013 23:22

YouTube: http://www.youtube.com/watch?v=aAb7hSCtvGw

by Joshua Bloch (Principal Software Engineer of Google)

 

API设计是重要的

对公司来说, API 很可能成为公司重要财产, 客户要购买, 学习, 停止使用API的代价过高, 并且, 成功的API可以帮助公司抓牢客户.  当然, 设计太烂的API也会拖垮公司.

对于程序员来说,  如果你写程序, 那你就是一个API设计师,  有用的模块会被重用, 但一旦被其他人使用, 那就不能随便更改.  如果在平时的编程当成设计API会提高代码质量

干货来了:

Characteristics of a Good API

• Easy to learn
• Easy to use, even without documentation 多美好啊
• Hard to misuse
• Easy to read and maintain code that uses it
• Sufficiently powerful to satisfy requirements
• Easy to extend
• Appropriate to audience

 

Outline

I. The Process of API Design

1. Gather Requirements – With a Healthy Degree of Scepticism

我们经常会收到解决方案而不是需求 — 所以我们常说, Product management/BA们不要提Solution.

我们的工作是提炼需求, 最好是以Use Case的形式.

(以前我有个Technical Manager, 他总是要求我们吃透需求, 挑战PM. 事实上, 如果暂时妥协, 接受未经挑战的需求, 可能会为日后的重构埋下伏笔)

Can be easier and more rewarding to build something more general

2. Start with Short Spec–1 Page is Ideal

跟领导演讲稿一样

“If you want me to speak for an hour – give me a moment’s notice; if you want me to speak for half an hour, give me a day’s notice; if you want me to speak for five minutes—give me a week.”__Winston Churchill

3. Write to Your API Early and Often

Code lives on as examples, unit tests

II. General Principles

API Should Be As Small As Possible But No Smaller

API should satisfy its requirements

When in doubt leave it out
_ Functionality, classes, methods, parameters, etc.
_ You can always add, but you can never remove

Minimize Accessibility of Everything

Names Matter–API is a Little Language

 

Document Religiously
• Document every class, interface, method,
constructor, parameter, and exception
_ Class: what an instance represents

_ Method: contract between method and its client
_ Preconditions, postconditions, side-effects
_ Parameter: indicate units, form, ownership
• Document state space very carefully

 

III. Class Design

 

Minimize Mutability

Classes should be immutable unless there’s a
good reason to do otherwise
_ Advantages: simple, thread-safe, reusable
_ Disadvantage: separate object for each value
• If mutable, keep state-space small, well-defined
_ Make clear when it’s legal to call which method

Subclass Only Where It Makes Sense

Design and Document for Inheritance or Else Prohibit it

Inheritance violates encapsulation (Snyder, ‘86)

IV. Method Design

Don’t Make the Client Do Anything the Module Could Do

Don’t Violate the Principle of Least Astonishment

User of API should not be surprised by behavior

Fail Fast–Report Errors as Soon as Possible After They Occur

快速失败

Provide Programmatic Access to All Data Available in String Form

Overload With Care

Avoid ambiguous overloadings,  If you must provide ambiguous overloadings, ensure same behavior for same arguments.

Just because you can doesn’t mean you should: often better to use a different name

Use Appropriate Parameter and Return Types

• Favor interface types over classes for input
_ Provides flexibility, performance
• Use most specific possible input parameter type
_ Moves error from runtime to compile time
• Don’t use string if a better type exists
_ Strings are cumbersome, error-prone, and slow
• Don’t use floating point for monetary values
_ Binary floating point causes inexact results!
• Use double (64 bits) rather than float (32 bits)
_ Precision loss is real, performance loss negligible

 

Use Consistent Parameter Ordering Across Methods

Avoid Long Parameter Lists

V. Exception Design

 

VI. Refactoring API Designs

 

Links:

Rule of three

The New Google Maps 新版Google地图

Categories: Development Notes; Tagged with: ; @ June 1st, 2013 15:26

Google 是个很炫的公司.

Google Map是个神奇的工具.

新的搜索条,  更加紧凑的利用空间.  灵活的跳转到搜索结果:

image

自动适应分辨率的调整. 在搜索结果中, 可以直接看到街景的预览.

 

下图为旧版:

image

相比之下 就略显笨拙.

Google I/O 2009 – The Myth of the Genius Programmer 技术大拿的传说

Categories: Development Notes; Tagged with: ; @ May 4th, 2013 0:19

Fitz(Brian W. Fitzpatrick) 与 Ben(Ben Collins-Sussman) 是Google的两位技术大拿, 这是他们在09年Google IO上的演讲:https://www.youtube.com/watch?v=0SARbwvhupQ

 

摘录/翻译 一点我觉得挺有意思的部分:

 

  1. How many people in this room write code entirely by themselves only.  Never with other people? or how many like writing code by yourself.
    这是一个问题. 很少有人完全独立编程, 但有很多人希望能够独立编程;
  2. How many people in this room do code reviews as part of development process?
    多数人举手.  所以, 如果所在的团队没有code review, 是不是该考虑开始code review 或是离开?
  3. Who is afraid of look stupid in front of people?
    多数人都不希望在别人面前犯二.
  4. Bus factor is the number of people on your software project that have to get hit by a bus that are gonna leave you in a world of hee.
  5. Lose the ego 放低自己
  6. Criticism is not Evil 批评不是恶魔
  7. At Google, actually, we’re not allowed to submit code into our version control system until there’s code review
    在Google, 在提交代码之前必须进行代码审查
  8. When failure does happen, be ready for it, don’t freak out, document what happened, what did you learn from it? what are you going to do different next time? write it up and learn from it
  9. Iterate Quickly: The faster you can fail and the faster you can iterate, the faster you can learn and get  better.
  10. Practice is Key
  11. To be a small fish: If you were the senior developer on a team or in a company or something, and everyone looks to you and you’re sort of the teacher, or the king, queen whatever, if you’re only working with people junior to you, you are going to learn things from them, but it’s gonna be harder to improve your skills.
    When you are a big fish in a pond, it’s very comfortable, but you’re not really learning very much. you feel safe, but you don’t get much better. and when you are a small fish in a huge pond, it’s very scary.
  12. Be Influenced: the more that you’re open to the influence of other people, who might have a really good idea,
  13. Be Vulnerable: If you can show yourself to be open to change and willing to admit mistake
  14. Case Study: Subversion
    It started out with three guys in an office writing a design doc together, just the three of them. Took up maybe two weeks or three weeks, to actually get it right.  two or three is best.  If you travel with more than six people, you can’t go anywhere…
    After we got design doc, we brought it to a larger forum, invited comments, put it up on a web site,  and began to get feedback. and then we just started coding,  amazingly, about a month or two later, we had some working, very basic working code, and suddenly, as soon as we had working code, suddenly all these people started showing up. we didn’t even advertise, but somehow, it was like we crossed the magic threshold. ( 9 years ago, it was only CVS)
  15. image
    If you do all these things, people will Think You’re a Genius.

Google宣布不再提供免费版的Google Apps企业邮箱套件

Categories: 分享; Tagged with: ; @ December 9th, 2012 21:25

Google 向您致敬,
我们有一些关于 Google Apps 的重要消息要告诉您,但是不用担心,您无须执行任何操作。我们只是想让您知道,我们即将对提供的产品包进行更改。
从今天起,我们不再接受 Google Apps 免费版本(即您当前正在使用的版本)的新帐户注册申请。由于您已经是我们的客户,因此这一更改不会对您的服务产生影响,您可以继续免费使用 Google Apps
如果您愿意升级到 Google Apps for Business,那么就可以享受全天候客户支持、25 GB 收件箱、业务控制、99.9% 正常运行时间保证、用户数量不限等优势,每位用户每月只需 $5。
您可以访问我们的帮助中心或 Enterprise Blog了解详情。
感谢您使用 Google Apps。
Clay Bavor
Google Apps 小组负责人

© 2012 Google Ireland Ltd, Gordon House, Barrow Street, Dublin 4, Ireland.
我们向您发送这封重要的电子邮件服务通知,目的是让您了解关于您 Google Apps 产品或帐户的重大变化。

以下摘自Google Enterprise官方博客:

we’ve decided to make things very straightforward. Starting today for all new customers:

  • Individuals wishing to use Google’s web apps like Gmail and Google Drive should createa free personal Google Account, which provides a seamless experience across all of our web services on any device.
  • For Businesses, instead of two versions, there will be one. Companies of all sizes will sign up for our premium version, Google Apps for Business, which includes 24/7 phone support for any issue, a 25GB inbox, and a 99.9% uptime guarantee with no scheduled downtime. Pricing is still $50 per user, per year.

看起来价格是$5/人.月, $50/人.年.

Google Apps 的免费版也要比国内很多收费邮箱要好很多, 看来要好好珍惜手头的账户了.

Older Posts



// Proudly powered by Apache, PHP, MySQL, WordPress, Bootstrap, etc,.