vendakka

Hi HN,

TimeFerret is a beautiful calendar app for iPhones and iPads. It comes with a custom keyboard that lets you access your calendar from any app.

How TimeFerret is different from other calendar apps: 1. Quickly see how much time you have between meetings in the 24-hour "Daily Donut" 2. Calculate Meeting Cost 3. Mark certain hours of the day as "Me Time" and flag meetings that interrupt this time. 4. Carve out a few hours as "Meeting Time" and flag meetings that are outside these hours.

We are happy to answer all your questions about TimeFerret and would love any and all feedback :)

Stencil implements GoImports formatting which is basically GoFmt with a slightly different import ordering. And yes, it would be useful to standardize this somehow, the way go generate is standardized.

The go vet integration with go test looks interesting. I'm currently using github.com/surullabs/lint [1] to run vet and a few other lint tools as part of go test. It provides a nice increase in productivity for my dev cycle. Having vet + other lint tools integrated into my dev+test cycle has caught a number of bugs before they hit CI.

[1] https://github.com/surullabs/lint

Disclaimer: I'm the author of the above library.

Ah right.

I wasn't very clear. A hypothetical conn.Read(w Writer) would call Write on w instead of filling a byte array. Write in turn allocates as needed. WriterTo is a cleaner way of doing this.

Exactly. The sync.Pool will only be useful if net.Conn.Read accepted a Writer instead of []byte.

Hi,

I'm the author. Please let me know if you have any questions or comments.

This library allows you to run a variety of linters as part of go test. It also supports whitelisting false positives. It reduces the need for build scripts, makes CI integration easy and lets projects enforce linter usage without extra scripts. I built it while working on our mobile app (which is written in Go) and have found it useful so far.

The below example test will check for gofmt usage, run go tool vet --shadow, golint, errcheck, gosimple and gostaticcheck

  import (
      "testing"
      "github.com/surullabs/lint"
  ) 


  func TestLint(t *testing.T) {
      if err := lint.Default.Check("./..."); err != nil {
          t.Fatal("lint failures: %v", err)
      }
  }

Please let me know if you find this useful and if you'd like any features added/removed/modified.

This is something I definitely agree with. I've sometimes found that taking a few seconds to cache state in a notepad before responding to the interruption helps a lot. Having times of day dedicated to meetings also helps reduce fragmentation. At the risk of being overly self-promoting, solving problems with fragmented work days is something my cofounder and I are working on now with TimeFerret (https://www.timeferret.com).

This is very good advice. I've had trouble with flexibility for as long as I can remember. I've recently started some light exercise again and including yoga for just 5 to 10 min has made an enormous difference.

I've used git subrepo [1] for vendoring and been quite happy with it. Doesn't seem to have the problems of git submodule and it's easier to use than git subtree.

[1] https://github.com/ingydotnet/git-subrepo

Would you be interested in trying our beta [1] once it's ready? We're working on the hypothesis that bad meeting schedules can result in a large drop in productivity, especially for software related jobs.

Our current solution is to make it easier to cordon off blocks of time and easily reschedule disruptive meetings using a mix of auto-suggested times and meeting polls.

[1] http://www.timeferret.com

Thanks for letting us know. I've updated the quota so the website is up now.

EDIT: Changed it to say the website is up, where it said the website will be up shortly.

Slightly shameless self promotion: If you're looking for an Android solution, we're working on TimeFerret, a calendar app that helps you reduce fragmented meeting schedules and track productivity. It's not released yet though. The iOS version will be out first, followed by Android.

[1] http://www.timeferret.com

Regarding generics: the tool generates Java bindings from Go code. Since Go doesn't have generics we just generate non-generic bindings.

Yes. The only constraint is that the jar will only work on the architecture it was built on.

Yes this is definitely a little limiting. I'm also experimenting with a slightly different binding method, where passing pointers to structs is disallowed (gobind currently allows pointers to structs). All structs are only passed by value, which solves a lot of the underlying problems and allows for slices and nested structs. I'll have something tangible in a few weeks and might switch out the dependency on gobind.

EDIT: edited for clarity

Yup. I'll put together some more docs and usage examples this weekend.

Edit: https://github.com/sridharv/gojava/issues/6

This exists for Python [0]. The reverse is also interesting (Go -> Java/Python/Ruby) and once I get some spare time, I'll play around with using libjvm to load and call jar files from Go.

[0] https://github.com/go-python/gopy

I've set up a business here without knowing German (I'm Indian). I moved here from the U.S and what worked for me was to pass all of this off to people who know how to deal with it. My lawyers handled the company set-up and my accountant handled everything else. It is pricey (thousands of euros) but worth it in my mind.

Conway's Law comes into play a little here. Microservices provide organization level flexibility at the cost of operational and development complexity. For small teams and especially at the start of a project, organizational flexibility is usually not needed. Paying the extra ops and dev cost is unnecessary and even dangerous.

In the above, when I say microservices incur ops and dev cost here's what I'm talking about

* Debugging tools need to function across machine boundaries

* Deployments potentially need to be scheduled in multiple stages based on the service dependency graph

* Developer and test environments become more complex.

* The number of failure modes increases due to the network.

All this means we need more code, tools and processes. This investment is worth it and even required for large organizations. They usually have the infrastructure in place and the financial resources to invest. When I was at Google building a microservices based system was so much easier with Borg, Dapper, etc. This kind of tooling is only now emerging in a useable form in the open source world.

EDIT: formatting, grammar

I've recently started working in node after spending some time in Go-land and the reverse applies to me. The code I'm writing is a mix of js + Go and I find that in JS I have no sense for what can go wrong since it's not obvious to me if a method will throw an exception or not. However, with Go it forces me to think about my error path.

I do find littering code with err checks can be annoying and ended up reaching a compromise. For all code that is likely to be part of an externally public package I use 'if err !=' checks. For application level code that will be internal to my application (and internal to the file I'm working in) I use a small library [1] I wrote, that uses the panic-defer-recover style talked about in the Go documents for internal error handling [2].

However, I find that in most situations I usually prefer to not use panic-defer-recover, with if checks providing more clarity.

[1] https://github.com/surullabs/fault [2] http://golang.org/doc/effective_go.html#recover

I just started working with javascript recently after a long time in Java/C++ land, and this really resonates. I get the feeling the javascript community is where the Java world was a few years ago. A number of the npm packages that I've used (and this could just be selection bias) tend to be frameworks rather than libraries. They do a lot for you, but they also choose how to do it. The net result is that in order to achieve something different from the original intention you need more code. The cycle continues indefinitely. The Java world was bitten by this with Spring and companions, but over time has evolved to be more library centric. The fact that javascript allows so much magic also makes the situation worse than what it was with Java. It'll probably take 5 years or so to settle down.

In the course of a few weeks, I've experimented with react + coffeescript, react + typescript and settled on react + jsx + flummox + react-router in es6. I've finally come to the realization that I need to read the code for all of these to have some sense of what is actually happening. Not doing so is leading to obscure bugs that take hours to chase down.

Transport Layer

I'd use HTTP with SSL on port 443. The ports 443 and 80 are whitelisted by a number of corporate firewalls and the like. I've run into problems in the past caused by blocked ports. In addition there is a large amount of existing software which already understands HTTP for things such as load balancing, caching, etc.

Encoding

I would recommend using JSON to begin with. It is extremely flexible and coupled with the compression abilities you usually find built into HTTP systems it will also be compact. I've used Protobufs (at Google) and Thrift (at my previous job) before, but find that the primary use case ended up being code generation and serialization using their respective description languages. This might seem absurd, but in my experience, since these don't allow you to embed the schema in the message their main advantage was reduced to having a very compact representation with some automatic schema evolution capabilities thrown in.

JSON might lead to some additional initial typing but provides very good performance in most languages. Storage of JSON messages can also be very compact if you store the compressed form. In addition most JSON libraries allow you to be backwards compatible when decoding messages (i.e adding new fields, etc).

When compressing, gzip can be expensive in terms of CPU cycles so consider using Snappy[1] from Google.

I've also heard both good and bad things about Avro but I haven't used it personally.

Most people claim JSON is schema-less but this misses the point a little bit. The JSON schema is the code you write detailing the various structs/objects that the JSON objects map to. Merely because there isn't a specific language used to lay out the schema does not immediately mean you cannot have a JSON schema. There just isn't a standard so use the library that works best for your language.

[1] https://code.google.com/p/snappy/

There is usually a fair bit of prototyping work involved as well. There's also a lot of listening involved, as you can't really design a good system without first talking to the people who are going to use the system and understanding their needs. In addition you'll need to listen to the folks who are going to be implementing the system as well so you get a feel for what they are good at and what they enjoy working on.

It isn't just the tone that I'd take issue with. The person who reported the bug is also implying that the library author is either negligent or incompetent. I consider this to be an extremely uncharitable attitude.

The library author is a person who's taken the time to publish their work for free. If one finds issues with the library, the polite thing to do would be to first ask about it instead of complaining. There are likely good reasons for this (and lack of time is a very good reason). A simple "I find you aren't supporting these emojis. Is there a reason for that and can I do anything to help?" goes a long way.