Hacker Newsnew | comments | show | ask | jobs | submit | diggan's commentslogin

Typeform - Barcelona, Spain (full time positions on site)

We are a startup located in sunny Barcelona, looking for more people to expand our wonderful team. We are looking for people filling multiple positions, some of them are backend/frontend developers, content managers, videographers and QA engineers.

We are working on making forms easy and enjoyable to fill out. We already got what we need to grow the team, now we just need the right people.

You can see at a glance on what we are working on from our website but don't be afraid to ask if you have any questions. See it here: http://www.typeform.com/

Some of the things we are working on this very moment:

* Building a new API with Lotus (framework in Ruby) for creating forms dynamically

* Taking existing parts out of the system to be able to scale them independently

* Making the infrastructure more fault tolerant

If you are interested in working with any of these or just came up with some other ideas that you think would make filling out forms more awesome, don't hesitate to fill out the following form to apply: https://jobs.typeform.com/to/e7NNgU

My personal email if you have any questions is victor@typeform.com


It does say "Version 1.0.1 (Beta stability)", what more are you requesting?


The "(Beta stability)" is just text on that webpage. The version is just 1.0.1.

By any sane logic any release after 1.x should be considered stable UNLESS otherwise stated.

This is why we have the concepts of things like "dev", "alpha", "beta", "rc" (release candidate) identifiers for versions.

Nowhere does io.js use any of these terms except in that homepage. So now, anyone relying on any other source to get the product either as source or in a binary package has no way to know if it's considered "stable" yet.

So what I want - basic common fucking sense is what I want. Nobody in their right mind would release software marked as version "1.0.0" with full knowledge and even the barest of acknowledgement, that it's only beta quality.

The explanation I've seen so far is that the people behind the fork are sick of NodeJS never reaching 1.0 despite being used in production. Sure thats a good reason to make it 1.0 - because a heap of cool kids have jumped on the bandwagon and bet their business on it, it must be stable right?

Oh wait, but then they admit that it's only beta quality. So they want it to be versioned as if it's appropriate to use it in production, but they know its actually not.


Because generally you're reading commits that happened before and you want to know what happens when you apply the commit.

It goes something like this.

"Hmm, I wonder what would happen if I merge 1231knf?"

It would "Add email integration on /email route"

Otherwise it would be something like

"What happens when I merge this commit?"

"Added email integration on /email route"

It's considered as best practice when using Git to write in present tense.


That's one interpretation. Another is you're looking at git log and it's all historical. The best practice bit seems to boil down to "because Linus said so." The rest of the git commit best practices seem to fall into a similar boat.

I'm of the mindset a team can be mature enough to pick what works best for them. If the idea of a commit message is to convey useful info, imposing hard rules like 72 chars or tense seems a bit draconian. The worst change GitHub has made IMHO is truncating messages (particularly because the truncated message often ends up longer).


The reason for the 72 character limit is so that shortlog messages on an 80 character terminal which are indented by one tab aren't truncated, as I understand it.


I get that. And in certain scenarios where even pagers aren't available require that. But I'd expect that team to handle it, not for it to be a general purpose rule. In contrast, a Nokia postage stamp feature phone can display a message more than twice as long (SMS - 160 chars). Limiting to 72 chars across the board seems to be more dogmatic than anything else from my POV.


I think that the boat already sailed, there are many tools that assume that shortlogs are 72, and can be displayed on a single line, and format accordingly, including GitHub for instance. Besides, whether it's 72 or 100, it makes sense to force people to have a concise summary.


GitHub's approach is one reason I've started using BitBucket more. GitHub didn't always used to do this. I've assumed they started so they could have fixed height commit displays in their commit list. It seems weird to force this on people otherwise.


Typeform.com - Barcelona, Spain - Frontend/Backend developer (also other positions, check out the link in the bottom)

Typeform is creating new ways to create forms on the web. We are heavily focused on great UX with the user in mind and we’re now looking for the best developers we can find us to help us build a scalable and maintainable front and backend.

As an engineer at Typeform, you should have a solid understanding of software architecture and design patterns. You should know OOP from the inside out and would be great if you have a strong desire to innovate, learn about new technologies and be ready to take a part in the building of the product.

As a front-end engineer at Typeform, you would be responsible for creating and innovating on every cornerstone in the front-end platform at Typeform.

As a back-end, you will need to be able to build and design large scale applications for our platform to support millions of form responses and provide realtime information analysis.

Read some stuff about what we done lately:

Online Survey And Form Builder Typeform Raises €1.2M - http://techcrunch.com/2014/09/23/typeform-raises/

Getting real survey answers out of smart, busy people - https://medium.com/@mia/getting-real-survey-answers-out-of-s...

Typeform Makes Web Forms Interesting Again - http://techinch.com/blog/Typeform

Apply here: https://jobs.typeform.com/to/e7NNgU

Or contact me directly at victor@typeform.com if you have any questions before applying.


Also called sub-addressing in RFC 5233[0] or Address Tags. Gmail is not the only one of the email providers that enables this. Yahoo, Apple, Outlook, Fastmail and others also support this. More information at Wikipedia: http://en.wikipedia.org/wiki/Email_address#Address_tags

[0] https://tools.ietf.org/html/rfc5233


Nice! Didn't knew that other providers do it aswell.


> Anyone who's done any serious web-app development in the past decade knows that cross browser compatibility at the bleeding edge (ie, past what the JS frameworks have worked out) can consume as much time as the rest of the application put together.

Sure thing. As a web developer, I also know that I NEED to follow CSP on every application I do. Something Google doesn't seem to do when running in Google Chrome.

I also know that adding two prefixes along with another prefix, isn't that hard to do.

If you want to be early, fast and get feedback, make sure your application works for more browsers than your own in-house browser. Because when you release it, people will surely use other browsers than your in-house browser.


Getting a product out in the web development world includes getting it out for other browsers than the browser you develop in house. Otherwise, you won't get the early feedback you wanted. Especially when your application is working, with some minor glitches.

It's not like the application is completely broken in Firefox with the fixes mentioned. Bypassing CSP for your own domains feels like a hack that you shouldn't be able to do.


Given how over subscribed the beta is I think they're getting feedback.

Remember with this sort of product the questions they have are "is this interesting?", "is this useful?", "do people like what this does?".

Can we get this running on Firefox simply isn't an interesting question to them - they know the answer, it's yes if they throw resource at it, but for a new product team with questions over whether this product should even exist that's not a priority.

Remember, this is Google who have a long history of canning this sort of project. If I were the company who produced Wave, I'd probably look at how I could reduce the cost and time to feedback for my next new thing too.

As an aside, I've tried Inbox and, to me at least, it's the next Wave, not the next Gmail.


Yes, it is indeed functional in Firefox, with some adjustments to their animations, it would be "running properly". And yes, they are going out of their way to make it run only in Chrome since all the rest of the browsers are blocked.


Going into your firefox flags and disabling content security policy does not count as "working in Firefox". Also the linked post reports performance problems.

Never assume malice when there is a perfectly reasonable explanation. They shipped an awesome product as fast as they could. Firefox support is probably coming soon.


> Never assume malice when there is a perfectly reasonable explanation.

A technical explanation? You mean like Google disabling security checks on their own domains, violating internet-standards?

Well yes certainly that would be a problem, unless they also controlled a majority-share browser.

Oh wait. Does this sounds like Microsoft of the 90s yet?


Thanks a lot for that information! Will include it in the post when I get a chance.

The performance is kind of bad in Firefox but I'm not sure it justifies blocking the entire browser because of that. For a comparison, Google Photos is slow as hell in Firefox, but you could still use it if you want to.


Google blocked Windows Phone from accessing Google Maps in the browser (both the desktop and mobile versions) with the claims that IE was unsupported, even though Google Maps UK worked just fine.

Google does have a history of blocking browsers they don't support, no matter how functional it may seem.


Yeah, they seem to use the whitelisting strategy for all of their properties. If something isn't QAed it doesn't get enabled. I suppose at that scale the support cost isn't worth the "let them use it in a degraded way" mantra most of the web community follows.



You can't get support out of Google at any price, unless you're an advertiser. But in that case, it's only help for your ads and nothing else.

You can't talk about "support cost" when it's zero.


"Support cost" doesn't apply only to customer support.


Go on, I'm interested - what extra cost do Google have if I use the same service in FF as I would otherwise have to switch over to Chrome to use; given that they say up front that other browsers aren't supported and that this is a beta so expected to be shonky.

What cost is there?

If I've switched UA string Google might not even be able to tell, without actively seeking out the information, that other browsers are using it - how then could that be an extra cost?

School me, please.


It takes resources (mainly developer time) to ensure that an application is working properly on multiple browsers. If you read the article you can see that a simple UA string change does not fix the problem.


There's a big difference between "provided a degraded experience in non-Chrome browsers" and "actively blocking non-Chrome browsers by means more invasive than UA checking"

Remember, there isn't any kind of really legitimate API for 100% determining which browser you're running in. There's a lot of ad-hoc methods which usually work.

These folks spent extra effort to block it from even TRYING to run in FireFox.

How are the FireFox devs supposed to see the bad performance that they need to fix for Inbox to work right if they can't run it at all?


There is also a big difference between "provided a degraded experience in non-Chrome browsers" and "you have to actively disable CSP (a global setting) for it to work in Firefox."

Also, with respect to performance, this comment in the article might shed some light:

"Also see Bugzilla entry. The use of spare arrays with huge indexes was a performance issue in Firefox. It's been fixed in Inbox and in FF but not shipped in FF yet. (https://bugzilla.mozilla.org/show_bug.cgi?id=1087963)"


But we're specifically talking about not hobbling other browsers not supporting them - you (or whoever) said that there are still support costs even when a browser isn't being "supported" (ie enabled to operate with a site at a suitable level).


Did you read the part in the article about CSP?


Even if they don't support customers they still have to support internal customers (everyone that works for Google). I worked on a project recently that didn't support IE8. Nevertheless, the day after release there were a ton of emails from one particular office that the site didn't work. There was a bit of a panic, various theories thrown out (it's working for everyone else, why is it not working for this office, networking issues?). A couple of hours (and who knows how much money) was wasted in an all-hand-on-deck meeting to fix the issue before it was found out that this particular office had an IT department that only allowed XP+IE8 machines.

When you get bug reports from internal customers it's never "the site isn't working in Firefox 33 with all extensions turned off. It loads but is a little slow.". The bug report you get is simply "it isn't working, you get a blank page".

Answering those types of emails cost real money.


Support cost doesn't mean customer support.


This probably has more to do with undermining WP (which is competing with android in the low end phone market) than anything to do with browser support. They would block iOS too if they could, but they can't so that's why safari is 'supported'.


Were there differences between the IE on mobile and desktop though?

I recall back in the IE5 days that IE on Mac was a significantly different beast than IE on Windows despite being named the same.


The engine was supposedly exactly the same on WP7, on WP8 the entire browser is the same with the exception of the UI (obviously). Google Maps UK worked fine on both the mobile and desktop site views of IE on Windows Phone.


If they'd supported Firefox from the start everyone would be slating them for "crippling" Firefox, or they would have had a poor user experience that would turn a non trivial percentage of early adopters off the entire product. They cannot win here, it was a bug in FF, it is now fixed, presumably they'll stop blocking when the fix is more widely available.


They could have made the effort to make this work on firefox from the start, but someone decided the effort wasnt worth it.

The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works. Firefox is fast enough if you write code with it in mind.

...but hey, who cares about anything except chrome right? If someone visits play.google.com on an ipad and safari crashes screw them for not using android right?

Its Business Politics at play, not technical restrictions.


>The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works

Not really. And here's a list of arguments why it's okay to focus on one browser (at least at first):

1) It's in beta, so you want to get it right before focusing on making it work everywhere

2) Developing for multiple browsers adds overhead to developers. I imagine they like to utilise some experimental webkit features, which are either not available in Firefox/gecko

3) Related to 2), they would add a lot of overhead making sure the UI and UX is the same, using multiple vendor prefixes and workarounds for other things.

And just to point out,

>dont release product until it works

is probably the worst advice ever to give to people. You want people to actually test your application. You can never catch all the edge cases that can/will happen, in your mind, and sometimes your assumptions are wrong. This is a pretty basic concept or Lean UX etc.


I'm sure it's different for large projects, but for my own work, if I wait until the app is "finished" (or at least in a workable state) before working on cross-browser compatibility, I hate my life and want to die. YMMV, but I find that working on compatibility from the start is the way to go. That said, if there indeed is a big performance bug in Firefox, that would totally be a valid reason not to support it (for now).


My counter is that "fix it later" never comes. Unless business sees browser support affecting the numbers they will not allocate the time to fix it. Some dedicated developers might fix it by working over time but that's essentially free labor. It has to take a strong engineering department to say "we will not ship until it works".


It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

If you plan to support cross platform, do so from the start.

You can argue about feature parity and 'first user experiences' all you like, but practically speaking, if you don't support the target platforms from the start, you're dooming yourself to FOREVER have 1st class and 2nd class platforms.

You see this all the time in apps; flagship on iOS, rubbish half implemented android version that launches 6 months later and never always gets updates 3-6 later, broken, with bugs. Or vice versa.

I'm not in any way saying that you should to be cross platform, or what platforms people should support. That's a business decision each business has to make. ...but it's not a technical decision. Technically, if you know what platforms you support from the start, you can implement the product with that in mind.

I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms. I dare say, business people who make decisions but don't have to actually deal with the consequences of them.

I honestly feel for the Inbox team. I'm sure there a lot of really tedious days ahead of backporting and bugfixing ahead for them (if google decides to make firefox support a thing).


>It's well documented that the technical debt you accumulate from prototyping and supporting only one platform is extremely significant; to the point where many people never go back and fix / rework / remake products.

Maybe in GUI applications, but not so much in web browser applications.

>If you plan to support cross platform, do so from the start.

You are already close to automatically supporting all platforms. The point of "not supporting" a browser, is to avoid tedious and time consuming testing of said browser, because CSS and JS works differently in every browser (although close to the same in webkit browsers like chrome and safari).

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through retroactively having to go back and support additional platforms.

Again, your arguments might apply to a OS application, but not to web browser "applications".

Generally, I also subscribe to the mindset of: make it right for one OS. Instead of: make it shit for all OSs, but usable.

Finally. Going out of your way to support platforms that _might_ be used, for an application that you don't really know if people will use in the first hand, is absolutely idiotic.

You need to know how, why and if people actually will use it, before spending time and money on supporting multiple platforms/browsers.

Just to finish of,

>I've literally only ever heard this sort of ridiculous rhetoric from people who've never suffered through...

I've literally only heard this from people that have never developed for multiple platforms, and expect that "once it works on X, it must work on Y". It just isn't so. Implementations, however neat, always differ in GUI-land.


If you put 'applications' in 'quotes' when you refer to websites, we are so far from being on the same wavelength its not even worth continuing the discussion.

I can only recommend you seek additional input from your immediate peers before writing your next web 'application'.

(hint: the considerable negative feedback re inbox not working in firefox is the kind of bad press companies would rather avoid)


*experimental Blink features


> The 'would have been bad experience to new users' is a strawman arguement. Solution: dont release product until it works.

Except that almost no one does it nowdays. MVPs, early launches, etc. Why Google should be held to one standard while every "innovative startup" is held to a completely opposite?

By the way, did no one read what Google itself has to say about Inbox? It's explicitly stated as not a replacement for GMail. They're playing around with UX idea. You can look at it as a very elaborate A/B test.


If it had worked in Firefox and Chrome, but not on Internet Explorer, what should they have done? Think about that...


> Its Business Politics at play

Or alternatively it's economics. Maybe someone, somewhere had to make a decision similar to "If we want a good experience that includes Firefox users from day 1 it will cost $x and delay launch by y weeks". And he had to sell that to his boss.

Even in a company as awash with money as Google, someone has to justify budget choices.


I would have expected this sort of comment in most forums, but not necessarily in a community where many members actually deal and grapple with questions of "what platform gets supported when" and understand that "effort not worth it" is not the same thing as "business politics"

I believe many people know and understand that it's not unheard of for Google to release app updates on iOS a couple of weeks before the Android version comes out.

And while I've wanted to visit app stores cross platform to add items to a wish list while on the go, and been a little frustrated by not being able to do so, it does seem like a bit of an edge case. Although I suppose with both iTunes and Google Play edge cases can still be huge.


This is an ancient lesson in software development. IIRC back in the early 1990s there was a beta build of Microsoft Office sent out to early adopters with full debugging turned on, and one of them wrote a newspaper review about how slow the new version was, despite the adopter being explicitly told it was a debug build and would be slower. "It's just to show off new features, not new speed."


In other words: performance is a feature. And thus, not wanting to ship a product with an important feature missing should be understandable.


Quite. Performance is definitely a feature of Google Inbox and it's very much appreciated. I think it's an excellent tool, and the rapidness of action responses is definitely a huge part of that.


Don't say "blocking" (or maybe that is preferred since the tone of the post is to insinuate Google is being evil) and say "not supported yet" since the product is still in beta.


To me, "not supported" means that no effort has been put into making it work and you can't expect any help, but also that no effort has been put into not making it work. If the only problem is performance, then "not supported" would imply that it can be used, but it will be slow and you shouldn't complain about it being slow because you're doing something to supported. If there's code explicitly added to make it not work on Firefox, then "blocking" is a perfectly good word to use.


I'd also like to point out that, if you read the bugzilla bug, it was fixed on the same day that it was reported!

Nobody from Google bothered to file any bugs against Firefox; it wasn't until a Mozilla engineer saw the Google engineer's complaint on the HN thread that he filed it and fixed it himself!


What I know, given the right vendor prefixes, transitions works mostly the same way on both platforms. I don't think it makes sense to only have transitions for one browser when it's trivial to support other browsers as well. The CSP issue I honestly don't know why that's so but I'm fairly sure they should be able to follow CSP on their own domains, just like the rest of the applications on the web have to do.

To me, it feels like Google has an unfair advantage on doing web applications when they can do stuff on their own domains that no one else can, unless they also develop their own browser with unique features.


To me, it feels like Google has an unfair advantage on doing web applications when they can do stuff on their own domains that no one else can, unless they also develop their own browser with unique features.

And legally dangerous, too. It's as if they forgot entirely about the half a billion Euros Microsoft shelled out for doing precisely the same thing.


or they bought the right people this time and are sure to be free from that fate.

remember that Microsoft wasn't sued out of the blue. competitor companies lobbied for it. if Google lobbies first they should be fine.


Looking at the CSP error, it looks like there's a blob being blocked, not some XSS from Google's domains.

My guess at the cause would be an CSP implementation difference.



Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact