HN user

vendakka

72 karma
Posts6
Comments47
View on HN

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 :)

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.

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

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

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

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.

MonolithFirst 11 years ago

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.

I started out thinking this was a little tedious and even came up with a little library [1] to use the panic-recover style handling within a package [2].

However, after a few months of writing code using that model, I find that I don't really like it and prefer the if err != nil model much more.

While this can appear to be a little tedious, I've found it extremely useful once I started checking code coverage in my tests. It makes it very clear which exceptional cases you aren't testing. This in turn makes it obvious how well tested the code is. I know from looking at my code coverage what kind failures I'm handling properly and which ones I'm delegating to the caller. This allows for better documentation where API users know what failure modes to expect.

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

I completely agree. I used to have a fairly strange sleep schedule that moved gradually till I was finally waking up at 2 PM. I'd then spend one night/day without sleep to reset it. While I got plenty of uninterrupted time it wasn't very quality time. These days, I work remotely from Europe while the folks I work with, work in PST. That means most of my mornings/afternoons provide uninterrupted work time. I find that I get a lot more done and I can handle all my meetings post 5:00 PM.

I'd say it boils down to simple respect for other people's time and your own time. The professor is up there spending their time teaching. The students are in an learning environment which a number people have spent their time (or lives) constructing. In addition, by choosing to enroll in the class or in the college the students have agreed to invest a portion of their time learning. Completely ignoring the class and doing something else on a laptop or phone says that the student in question believes the course or college is a waste of their time. While that may be a valid point to make, I feel it is cowardice to make it by ignoring the people around them. It could just as easily be made by letting everyone know they think the course is a waste of their time and then leaving the course. Even better, they can stay and try to improve it. This way the people who are interested in the course can continue it in an environment where everyone is actually interested in the course. From my experience, something as simple as having everyone paying attention makes a large positive difference in how participatory and enjoyable a course can be.

Thanks for replying.

What you say does fit with my intuition. If I wanted to start looking for a job now I'd talk to the folks in my network at various startups / the Googles or Facebooks of the world.

However, it does make sense that a connected recruiter would help with looking for opportunities outside of that sphere as well. The suggestion to ask for referrals to good recruiters and sort by frequency is a good one. I'll keep it in mind for the next time I start job hunting.

Thanks again!

Do think a company like 10x would be more helpful for freelancers vs people looking for salaried employment? In the latter case I can easily see an experienced and talented person interviewing at multiple places and choosing the best fit.

Seen in this light, the comments from Chris Fry and Sam Altman make sense. If you're looking for employment, have a very good resume and a good network you might not need an agent. However, they don't seem to be considering the case of freelancers who need to spend a large amount of time finding clients.

Given that I haven't worked as a freelancer this is something I know little to nothing about. Hence the question.

Cheers and all the best with your work!