Square (https://squareup.com) | Multiple Openings | Full-Time | Onsite, Visa | San Francisco, New York, Atlanta, Melbourne AU
Software Engineer (Front End), Developer Platform
San Francisco, CA
https://www.smartrecruiters.com/Square/743999687141709
Come build Square's developer platform, where we succeed when our merchants and developers succeed
Engineering Manager (backend), Payment Acceptance Reliability
Atlanta, GA
https://www.smartrecruiters.com/Square/743999686815853
Help us reliably scale our payments platform while also leading agile development of important new products.
Android Engineer, Square for Retail
New York, NY
https://www.smartrecruiters.com/Square/743999688147624
Come be a part of a small team building the future of Retail! We need your help working towards launch on our new flagship Android platform.
Android Engineer, Square Ecommerce
San Francisco, CA
https://www.smartrecruiters.com/Square/743999688147624
Ecommerce team at Square has top-rated website and commerce store app in the Play Store (under the brand name Weebly). We need your skills and expertise to take it to the next level.
Senior AWS Security Engineer
New York, NY or San Francisco, CA
https://jobs.smartrecruiters.com/Square/743999689064518-seni...
Square is moving hundreds of services from on-prem infrastructure to the cloud. Join a new team which will ensure this transition is secure!
To me, this means asking the following: when you do something, do you feel guilty after? Do you hate yourself for playing 5 hours of video games every night when you know you could be productive? That's a guilt-laden activity.
For some, the video games might not even be games they particularly enjoy—just grindy/addictive games that have a superior numbing effect or sense of progress.
If front-end MVC Is too much for a given use case, then Twitter's Flight.js[1] seems like a great way to keep jQuery well organized. It defines a way to write jQuery components that communicate via events, piggy-backing on the DOM's event propagation. Quite simple, and ideal for when a single-page-app (e.g. the kind you get with Backbone) isn't quite right for you.
This is somewhat minor, and a bit tangential to the article, but worth noting nonetheless.
The title on HN is misleading. Dev Bootcamp is a company whose name in the general sense is being used to refer to similar learn-to-code schools ("dev bootcamps"). This article refers to one of the latter, but does not identify as having to do with the Dev Bootcamp.
How often are (production) mobile apps using these types of BaaS providers rather than being custom-backed? Is this a tool mostly used for test/toy apps?
I'm surprised more public projects don't run as bounty-style "build x and get $1 million" type systems. Rather than picking who's going to do what (or worse, building all in-house), having many different small times competing for one pot seems like it might be a better way to get a good starting foundation. Or perhaps that's a crazy idea for something as big as this.
Who has time to build a $1M system and only potentially get paid for it? I know the basement Lisp hacker[1] probably thinks he could cobble it together in a weekend, but the reality is that these are huge systems. How could you get a team of people to build a system with a $1M budget without knowing if they'd ever get paid? How would the bounty be awarded? How would they know the winner produced software that is up to snuff? Would there be multiple parallel betas? Would this system encourage people to cut corners? Would the person choosing the winner be able to just give their buddy the prize and turn down everybody else?
[1] at this very moment I'm in my basement, hacking on some Lisp
Do you think any decent consultancy is going to be willing to invest millions of £ into building a system where they will most likely be able to recover none of it?
OTOH , more uk government code is being released as open source. So in theory any developer could study the source and offer to fix bugs/add features and give a more accurate estimate. This might increase competition.
Because the best aren't going to put good work into a project that will probably just get thrown away.
If you entered a bounty project with two hundred other entries (all of which have systems similar to yours), would you put hundreds of hours and all of your effort into the project in spite of the fact that there's only a 0.5% chance you'll get paid? Not if you want to stay in business.
The size of the project is barely even relevant, take a look at bounty programs that are up now for areas like design (99designs, etc) and how they are chastised for pumping out bad products from designers who are only putting a fraction of effort into the projects.
This type of system sounds great for those looking for cheap labor, but in practice it falls apart.
It might not lead to savings though. Suppose that the normal contract price is $1,000,000. If you have a bunch of small firms try to build the system, each on only gets the reward with probability p = Prob(they succeed and they get picked out of all the successful firms). A firm would only participate if the reward were greater than $1,000,000/p.
Can someone explain this to me like I'm a 5 year old and have no idea what any of it means? What will it help me do that I can't otherwise? What tech does it compare to, if any (direct competitors)?
One difficulty with building large single-page web applications is having a decent component model.
Right now, web pages are mostly composed of primitives (divs, etc) which are the building blocks for complex UIs, but there's not a first-class way of bundling these together into richer components such as a tab control, or a data bound listbox.
The web components basically standardize a way to encapsulate more complex UI components, so you can do something like: <x-tab-view></x-tab-view>.
Even beyond a rich community of pre-built components for you to consume, they make it easier for you to make your applications composable-
<my-header></my-header>
<my-paging-content>
... lots of content ...
</my-paging-content>
<my-footer></my-footer>
Hopefully this all makes it much easier to build larger single-page apps.
In my opinion the worst thing about WebForms were statefulness almost everywhere and very complicated page lifecycle including the refresh of nested components. For small applications it's great, but has problems when you're trying a large, dynamic product. Composability is much easier with MVC, where you can link to controller actions instead of always depending on the way nested controls process postback events and rebuild themselves.
Exactly. I actually kinda liked the ideas behind WebForms - the ViewState thing was a clever way to shoehorn statefulness into the Web. But the abstractions in it were so leaky and brittle as to be worse-than-useless. The page lifecycle was a nightmare, data-binding was frustratingly finicky about types and parameters (and it was always a roll of the dice whether a given component would use empty strings or nulls to indicate an empty value) and so on.
Web forms was full of half-assed abstractions. Every postback it re-built your control tree and re-applied the viewstate, but any actual additions or removals of controls made in code-behind were not part of this rebuild and viewstate application, so it completely half-assed the control rebuild and thrashed its own abstraction. If you added a new control dynamically on one postback, you had to re-add it every postback, which demolishes the stateful model it presents with respect to the properties of controls.
What was wrong with it? I haven't used ASP at all (outside of some tutorial a decade or so ago), so I don't know. Curious to see if there are any pitfalls we're headed for, and if they're avoidable.
In the meantime, I'm quite excited by the idea of web-components, though the implementation is staggeringly unpleasant to look at.
Adobe Flex was also completely based on this "components" model. I would say that it is a useful approach, but as you suggest, not without its pitfalls. Adobe mxml was pretty much the same as this is: xml based markup, with custom components, these in turn implemented in a combination of mxml markup, AS3 scripts and css styles. I was a flex early adopter, and used it for some years. Later I abandoned it, mostly because I got tired of writing excessive boilerplate code in java-styled AS3, and also because html started to evolve. I can remember some tips. Please excuse my diffuse language, I am talking straight from memory.
- Avoid messy component structures. Keep component definitions simple. Use components hierarchies and keep nesting levels simple.
- On complex UIs, "application intention" can get lost in a sea of anonymous data bindings. Use good documentations practices. Avoid data binding spaghetti.
- On complex UIs, Use good planing for data binding. Because debugging it is "data binding hell".
- Know your components well. Sometimes components capabilities may differ slightly from what you are trying to accomplish. Trying to go against the components quirks, can be very expensive.
- Data binding is not the panacea. There are scenarios that are best served with other approaches.
It perverts the web's statelessness. It imposes some half-assed, hacky state via "viewstate". You have to constantly prune the amount of viewstate which controls add to a page, or you end up with 50kb of viewstate in the markup!
It is incredibly complex! The event model is difficult to understand, there are many steps - at a page level and later at a control level. I've never met anybody who truly understands it. You have a problem? Trial and error and sticky tape until you get it balancing just right that it works. Change with caution!
Promotes highly coupled code. The "code behind" all but begs you to put your business logic in your view. Testing is basically impossible, unless you adopt a framework like WebFormsMVP. This eases things somewhat, giving a cleaner model to work with and forces you to move business logic out of the view. But that can be a challenge on occasions too, because you eventually have to deal with the complex event model underpinning the framework (as I described above).
WebForms is basically demoware. Looks great when you drag a few controls on a page, click a few buttons, and have it pulling data into a sortable/filterable grid. As soon as you want to produce clean markup, styled as you want, performing some complex interactions, you'll end up wanting to pull your hair out.
Disclosure: I've worked with webforms for around 4 years.
They also allow you to plug the inputs of one component into the outputs of another in a declarative way with model-driven views. So, if you have a menu that allows a user to choose a piece of data to work with, you can do something like this:
I haven't used the library yet, so I'm sure the syntax is wrong, but you can see how x-item-editor can know which item to edit by consuming the select's value property, without needing any glue in the JS.
The modern web app has gone way beyond the simple HTML page - now there are components in all but name, handling their own libraries, network connections, establishing model-view-controller separation, and communicating with other components via events. But it's all simulated out of the technologies originally made for web pages.
One sign that things have gone very wrong: a lot of developers have to treat the web page as a kind of compilation target. We've lost the simplicity the original web had.
The authors believe in a future where if you wanted a particular rich text editor in your web app, you could just put <my-rich-text-editor/> in there. Done.
No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future.
As another poster mentioned, it's attacking the same problems as Angular.js, with a similar approach. Indirectly it's competing with pretty much every client side web app framework.
No web browser can do this stuff today, but libraries like Polymer are trying to bridge the gap between today's browsers and the way they may look in the future.
We should probably stop calling them "web browsers" at this point. We've basically re-implemented the idea of an Operating System in the browser, so we now have a full-fledged OS like Linux, BSD, Plan9, OS/2, Minix or whatever, being used to host a "poor man's OS" which is recreating most of what the base OS does!
To say "things have gone very wrong" is a dramatic understatement in many ways. I still think we messed up by migrating away from the mobile-code approach for apps. But I largely blame Sun for that, as they screwed the pooch by shipping the Consumer JRE about 7 years too late, ignoring needed features for doing desktop and interactive apps (like modern audio and video codecs, etc.) and didn't stay on top of JRE security. Now, Java, which was probably the best "mobile code" platform that ever got mainstream traction, is basically dead as a client platform. :-(
Browsers are great for doing what they were designed to do: Browsing hypermedia. But to shoehorn "remote application delivery" into the browser seems like a step sideways (at best) to me. We're layering hacks on top of hacks on top of hacks now, to try and recreate the "app" experience inside the browser. This strikes me as sub-optimal.
The web is still for documents. It's for a resource that lives at a URL. It's markup, not programming, and that's the very reason it has lived to be twenty years old and the main way that information is communicated. It's how we're able to hold this conversation right now — people are comfortable stitching together words in XML-ish constructs.
The people making games, applications, and lush webGL marketing demos are people who can throw lots of engineering resources at a problem until it does the thing they want it to do. Web dev has always been an insane mountain of hacks in order to get pages to render, but the attractive and democratic reasoning is that that extra effort is worth it if the maximum number of people can access the information. People on old computers, cheap smartphones, kindles, chumbys, whatever. The best computer is the one you have on you, that sort of thing. Access and ease-of-adoption are powerful things.
So that's why I see web components as something that enables people writing markup more than it empowers people writing giant javascript applications. This is so that people can add <twitter-tweet href="twitter.com/name">My Cool Tweet</twitter-tweet> tags to their wordpress blogs, and so that the people making that <twitter-tweet> tag can be confident that it will render and not look horrible on that person's blog. It's so that the complex, app-ish things can be abstracted away and added to documents with a declarative and logic-less syntax.
No amount of java applets would have ever made up for that.
So that's why I see web components as something that enables people writing markup more than it empowers people writing giant javascript applications. This is so that people can add <twitter-tweet href="twitter.com/name">My Cool Tweet</twitter-tweet> tags to their wordpress blogs, and so that the people making that <twitter-tweet> tag can be confident that it will render and not look horrible on that person's blog. It's so that the complex, app-ish things can be abstracted away and added to documents with a declarative and logic-less syntax.
Sure, and to the extent that Web Components do that, they are a good thing. Where I think we've gone a bit wonky is more on the "giant javascript applications" where we're using a great document delivery platform as a half-baked application runtime.
For better or worse, the way software delivery has evolved on the web is that documents contain applications.
I think that if we had known where we wanted to go, it may have been better to start the other direction, and make a web app API that basically allowed apps to contain documents. That would have avoided significant amounts of pain, and ended up looking more similar to what we have anyway -- web apps wanting or needing a larger and larger degree of extension-like autonomy and permission sharing with the browser.
Of course it's sub-optimal, nobody is arguing against that. But from where we are today, there is no other way forward. There's not going to be another technology suddenly spring up that will replace the browser and allow websites as well as apps to run on any device in a matter of seconds, without installation simply by typing a short address and hitting enter. We're layering hacks upon hacks, but you'll just have to deal with it and stop complaining at some point, because no matter how much you'll complain it won't change.
There's never only one way forward. Besides, how does the old saying go:
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
So who knows, maybe somebody reads one of my rants one day and goes "Hey, this mindcrime guy has a point... and furthermore, I see a better way to do this" and takes some initiative. Who knows what might happen?
Now, are the odds of that infinitesimal? Probably, but that's OK. I ran for public office (and lost) as a Libertarian, so that tells you what I think about odds. :-)
Like Angular.js from an end-user/developer's perspective but goes beyond that. Instead of being a framework it is an effort to polyfill the actual Web Components spec.
This means that Polymer will eventually be supported natively by browsers which means that in the future we'll have something like Angular without needing to do the heavy-lifting at the framework-level.
A "web component" is some stand-alone combination of HTML/CSS/JS that does some thing. It should not conflict with the application that uses it in any way. It should, however, allow the application to communicate with it (to modify its state) and to potentially change its appearance in a way that will not break the component.
A problem with HTML/JS/CSS pre-shadow DOM is that it was impossible to actually build a component as described above. There was no way to sandbox the HTML/JS/CSS that's used to build the component from the application. There was always the possibility for contamination.
What the specs that Polymer is intended to polyfill permit is a combination of this sandboxing capability along with other means of permeating this sandbox with the functionality needed for such sandboxed components to be truly useful (how useful is something you embed in your page then can't access/talk to at all?). This includes data binding, events, allowing parent CSS to apply to certain things (in a very explicit, named way, which allows the parent application to style the component in a manner the component creator deems appropriate, and not in a way that will break the component), etc.
These standards, in effect, define features that once implemented will permit true web components to be built.
I think AngularJS has more features but Polymer is more modular and designed to be more easily adoptable over time and also fit in with Web Components. I also think that a few things in Angular are hard to figure out, whereas this looks a little more straightforward. So if this Polymer thing could add some of the stuff that Angular has like routing with pushstate then I will definitely consider using it.
Software Engineer (Front End), Developer Platform San Francisco, CA https://www.smartrecruiters.com/Square/743999687141709 Come build Square's developer platform, where we succeed when our merchants and developers succeed
Engineering Manager (backend), Payment Acceptance Reliability Atlanta, GA https://www.smartrecruiters.com/Square/743999686815853 Help us reliably scale our payments platform while also leading agile development of important new products.
Android Engineer, Square for Retail New York, NY https://www.smartrecruiters.com/Square/743999688147624 Come be a part of a small team building the future of Retail! We need your help working towards launch on our new flagship Android platform.
Android Engineer, Square Ecommerce San Francisco, CA https://www.smartrecruiters.com/Square/743999688147624 Ecommerce team at Square has top-rated website and commerce store app in the Play Store (under the brand name Weebly). We need your skills and expertise to take it to the next level.
Senior AWS Security Engineer New York, NY or San Francisco, CA https://jobs.smartrecruiters.com/Square/743999689064518-seni... Square is moving hundreds of services from on-prem infrastructure to the cloud. Join a new team which will ensure this transition is secure!
See all our openings at https://squareup.com/careers/jobs