A reprint of my comments on the Philly Startup Leaders lust about this article:
The author’s Twitter profile lists him as “reporter for the Inquirer on Comcast Corp…”
Based on the content of his article, is say he is incredibly disconnected from the actual entrepreneurial community in this City.
His condescending attitude towards the N3rd Street corridor is laughable. Only Mitt Romney (or Brian Roberts) would characterize Old City as “low rent.” As someone who built a business in Old City, I can attest to the fact that the community there is packed to the folks with effective, serious minded entrepreneurs, not just “coffee-fueled techies.”
This piece is, at best, a lazy stringing together of cliches. This sentence probably speaks for the whole article: “He liked learning the corporate culture at Comcast and visiting the city’s museums.” Yep, that’s pretty much every 19 year old I know. Especially the ones who have Comcast’s PR people writing their quotes for them.
I suppose the underlying premise of the article is that if it’s not spearheaded by Comcast is just a bunch of cute kids playing at business.
On a positive note, I think this city has an awesomely diverse startup culture. The experience you’ll have in Old City is entirely different than the one you’ll have on the other side of the Schuylkill. That’s what makes this city of neighborhoods so great. Comcast adding another flavor to the stew is really a good thing. This article, not so much.
We live in unprecedented times here in the city of Philadelphia. While revitalization has swept the city, two under-served groups have been needlessly suffering due to political fat cats and their insatiable greed. The first of those groups is the our school children.
Clearly we can’t rely on the teachers who haven’t learned to teach without books, school supplies, or healthy children. I mean, come on, where’s the can-do attitude that can overcome physical reality?
Who does that leave us with? The children. I mean, why should they freeload off the hard work of the rest of us? The question is, where could they work. What organization could generate enough mindless labor to sustain such a workforce?
That brings us to the second community group in need of our help, the carpenters union. The Carpenters District Council is unhappy with the draconian work conditions at the Convention Center. They are forced to work in an environment where laypeople are setting up card tables and using consumer grade power drills. The convention center also is unfairly expecting the union to provide enough staff to not run into overtime hours and for that staff to work at a reasonable pace.
Here’s how we kill two birds with one stone. First, we replace all of the union carpenters with Philadelphia school children. The hourly costs of a union carpenter include $39.90/hr in base salary and $26.74 in benefits pay. Since schoolchildren don’t really need be benefits (thanks Obamacare!) we can just pocket the whole thing for a total of $66.64 per hour.
Let’s finish the math:
That’s only 15.78 hours per child for the whole year! That’s only 20 minutes per week. Wait, you say, there aren’t 3,000,000 hours of labor needed at the Convention Center. That’s easily solved, just add foreman. It’s what we’ve been doing for years!
Today I wrote an EDI visualization tool that lets you reformat complex ANSI X.12 EDI documents into a more readable format.
It also allows you to show/hide elements by type, so you can focus in in the information that’s most important to you.
*assuming reading EDI documents is your definition of fun
Today, we’re releasing an open source Ruby Gem called “aws_xregion_sync”. (This is what happens when we name projects without the marketing department!)
We use this tool internally to synchronize our AWS AMI images & RDS database snapshots across multiple Amazon regions as part of our disaster recovery process.
Basically, whenever we create a new disc image or take a database backup, they’re sent across the tubes to our disaster recovery region.
For more technical jargon, check out the Readme doc.
I’ve made a couple of lengthy comments on this Google+ post that some may find interesting. Basically, we’re trying to explain that having specific business rules for routing or validation are fine in the front end of a web app, but that those same rules mustbe re-implemented in the back end in order to prevent bad requests from wreaking havoc.
To quote myself…
It’s fine to have non-security related business logic in the front end as long as the back end doesn’t rely on it being there.
For example, if you have a site that builds quotes for loans, you might build the monthly payment calculation and fees into the front end for performance reason. However, your back end should recalculate these amounts independently before confirming the loan.
A good approach is to assume that someone is going to use your back end via API call that you didn’t write. Therfore, your back end should be fully secure and self contained.
From the original poster…
I am with you all - it is always good to have couple of logic / validations in the front-end but is it secure to have PUT method in the front-end too? Because this can be a big injection impact if we do this. If the server is hacked the PUT method can be dangerous right? You might have seen lot of CRUD applications, but I feel when inserting the data - I feel it is good to do in server end rather than front-end, am I right?
In the context of what we’re talking about here, all of the HTTP verbs (PUT, POST, GET, DELETE, etc) have the same concerns. The issue is that whatever you do on the front end will ultimately result in some message going back to your server. That message has to be validated on the server side when it comes in.
Sometimes it’s easier to think of this by imagining that the front end program and the server are being written by two different people working at two different companies. The only thing that each of them knows about the other is the API that’s published.
The server side says, “I’ll accept a PUT when you need to update the information in the database, but I’m going to double check that you’re logged in and that the data you send me is properly formed.
"If you’re not logged in, I’m going to throw your request away and return status 401. If you send me a 3 digit phone number, I’m going to throw your request away and return status 400."
The client side (front-end) programmer can (and should) do whatever logic he wants in the interface to replicate the business rule that phone numbers need to be more than three digits. He doesn’t have to put the checks in place, but if he doesn’t, the user will experience errors. If he does, he can catch the user’s mistake before it goes to the server, which results in a much faster system.
If that doesn’t help, comment with a more concrete example of what you’re trying to figure out.
Everything is an opportunity.
This morning, we were concerned because our customers couldn’t get to vital tariff information because of the government shutdown.
By lunch, we’d built this: http://www.vfitrack.net/hts
A few months ago, I noticed an area of our application that was performing terribly. It had always been slow, but with increased volumes, the issue was becoming more pronounced.
I wrote it in a rush while getting ready to demo our first prospective customer. It was the feature that got us the sale. It doesn’t have proper test coverage. It’s code is a messy stream of consciousness.
Only a handful of users use this particular feature, but they represent our core power-user group. Unfortunately, they haven’t been complaining about the slowness. They’ve simply become accustomed to it. Their silence gave me the perfect excuse to sweep the problem under the rug.
Every time I was about to dig into the code, I found a shiny new feature to write. Every time I was about to ask a teammate to do it, I remembered how shoddy the work was. I was embarrassed to hand it off.
This morning, while working on another feature that had to be implemented, I realized that I was going to have to dig into the problem code to make the new feature work. I took a deep breath and dove in.
An hour later I was done. Seriously. I had tests written for the old feature. I had tests written for the new feature. I had the performance enhancement in place (which turned out to be 2 lines of code.) I had the new feature in place.
The sad part. Our users, people I have personal relationships with, have had to suffer through the poor performance because I couldn’t muster up the courage to get in there and fix the problem. The effort I put into avoiding it had to be 10 times the effort it took to fix it.
What have you been avoiding?