Experience w/Chargebee and it's quite robust. You'll still need a payment gateway Stripe/Braintree/Paypal as they don't do CC processing (CB does integrate with them), but if you need subscription management, coupons, etc. there's a lot that CB does.
+1. To my knowledge Discord is and will always be intended for gamers for the forseeable future. They don't have the infrastructure to support enterprise expectations like LDAP/SSO, dedicated account managers, support hotlines, guaranteed SLAs (although I know their tech team is highly competent), etc.
1pw user here and long time AD architect. If you have any questions around AD/LDAP, I'd be happy to answer what is 'common' when dealing with AD-integrated solutions.
I think this has potential, but there are so many usability issues that it's quite difficult to use effectively.
A few examples (only talking about laptops):
-Labels on the sliders are unclear. If I select 4GB of RAM, are the results showing only those laptops with 4GB of RAM? or those that are >= 4GB?
-No distinction between configuration options & laptop models. On first load, it appears that there are 100+ models to choose from, when in reality it's probably much less with several configuration options.
-Possibly Bad assumptions that will affect data integrity. Amazon is not a reliable source for laptop specs or models because many products are fulfilled by 3rd parties that sloppily input specs and are inconsistent on where details are located. For example, the model number might be in the title, details, technical specifications, or Q&A.
-Odd defaults. Why do I start out looking for laptops with 1GB of RAM & 16GB HDDs ?
I'll check back periodically and keep an eye on this. My first thought is to take the best pieces from newegg.com and emulate those as they got filtering right in many ways.
My $.02 is focus on getting the experience / specs reliable and THEN add pricing. You might be spreading yourself too thin trying to tackle pricing as well.
The stats that would be hit the most obviously would be bandwidth, followed by RAM.
Storage requirements would change of course, but
bandwidth would be absorbed by whatever CDN they're using, so traffic quantity stat would be different.
Also, with images/videos, they're now sending more URLs/embeds/etc. along with data, so more characters = more RAM for caching and/or serving up on web servers. In theory, shouldn't be much more of a hit.
Thanks for the reply Brent, a few points I should clarify.
> Luckily they were able to get the Microsoft SQL team engaged to get them through this.
Looking at this statement now, I see that it might have appeared that Microsoft 'came to the Stack team's rescue.' My impression was that over time Microsoft alleviated some of the workarounds the SO team was running into.
> I'm not sure many teams would pursue this architecture if they knew the effort (and luck) involved.
I was simply stating that the SO architectural graphic looks deceptively simple and I can only imagine the amount of drama on hardware alone the team went through to achieve their goals. I do believe there are other OSS-based architectures (with likely more layers) that would require less 'workaround' effort to deliver reasonable performance/reliability, but compounded with SO's likely SLA & perf requirements on a closed-source RDBMS? It wouldn't surprise me to see some go 'good enough' and move on. I doubt anything is Ron Popeil easy when your trying to shed milliseconds on a persistence layer.
It's probably worth noting a few things about StackExchange's uniqueness for those that may not know.
StackExchange runs on physical hardware and they have spent a considerable amount of time optimizing for bare metal performance. Their team is unique in that they embraced hardware from the start vs. many teams today that want hardware abstracted away. They have more maintenance overhead around hardware management, but don't experience lost IOPs due to IaaS (AWS/Azure) overhead.
Their current environment required overcoming tremendous technical hurdles on earlier versions of SQL Server (these might be general RDBMS limitations as well). Luckily they were able to get the Microsoft SQL team engaged to get them through this.
Finally, their team was world class. BrentOzar, SamSaffron, MarcGravel (and others) are highly respected members of the SQL & .NET community.
It's easy to look at their setup and say "Wow, that's not a lot." and overlook the circumstances & talent required to achieve such an efficient system. I'm not sure many teams would pursue this architecture if they knew the effort (and luck) involved.
This article was pretty interesting to read, but unfortunately drew one incorrect conclusion...
"I guess my point is, that if you want to become a programmer, you have to be comfortable with having to learn new things constantly for the rest of your life."
This conclusion implies the rate of learning experienced in those 6 months would be the same forever, and I think that's not entirely realistic. While technology is rapidly changing, it's FAR more sustainable to maintain knowledge across a wide variety of areas than continue at the pace and breadth the OP experienced.
Also, it depends on your field/focus. If you're talking about web programming, sure. If you're a C++ app programmer, chances are your world isn't changing too dramatically each year.
As a Chicagoan trying to build a social network, I can say that this article hits a little too close to home; our ecosystem is completely dysfunctional. Go to a start-up event, and you'll see mostly service providers and FTEs that aren't willing to get engaged in anything new unless there's an income attached to it. Talk to investors, and they're mostly looking for traditional income streams or cashflowing properties. Any tech talent is either still in college (not terribly useful), or happily employed at corporations and NOT looking to change their disposition. It's been an ongoing struggle.
I worked in Santa Clara for 1.5 years and I love the Nor-cal energy, and while I there are plenty of pluses to Chicago (and the Midwest) in general, I must agree that a Twitter or FB would probably never have been successful here. For any Midwesterners reading this that disagree, I would ask if they've ever tried to rally Midwest resources around a project that isn't creating revenue within 90 days of launch.
Btw, if your an HNer in Chicago, or a tech/design resource interested in chatting let me know :)
As someone that's bootstrapped for 3 years, I can say that working hard is imperative, but can also be incredibly detrimental to your business. I believe in the spirit of the blog post, as long as you don't get caught up in absolutes, because obviously burnout is counter-productive.
Most startups I see are weekend projects, or 3-6 month endeavors that really don't qualify as being a part of history and are dominated by goal of making money. However, considering the author it's safe to say that Arrington is assuming that you're actually trying to MAKE A DIFFERENCE, instead of building the next coupon loyalty program with game theory and achievements. It's probably also safe to say that someone with his universally accepted work ethic is probably seeing alot more 'whining' in his current role than previously exposed to.
That couldn't be further from the truth. If I make mistakes, websites, phone systems, <insert service name here> become inaccessible for an unknown duration. That's best case. Worst case, data loss. Depending on the nature of the outage, it could ruin the company.
Try selling to a potential customer when their email domain continues to get bounced, or their voice mails never reach you and you'll find out very quickly who has a greater impact on the organization.
CS/CE offer no discernable value to the IT scene, unfortunately. Define 'take care'. Not install spyware knowingly? Ok great. How about making sure that software you install don't conflict with regular updates that are made to all systems every month? Or what about making sure that you're not introducing problems in the areas of authentication or monitoring, by changing specific settings or services that are running for a purpose. Unless you have ever worked in IT, you likely have very little knowledge on the havoc you could cause for seemingly simple changes.
As for JRE vs. VLC, how do you JRE's status isn't simply a false negative? How many applications in your organization actually utilize the JRE? Is it a non-issue? Are you aware if there are any measures already taken to mitigate known JRE exploits? There is quite a large difference between exploits that exist in an environment vs. those that exist in an application that you actively execute.
Granted I'm not defending the specifics, I personally think VLC is likely fine. But that doesn't change the points made above. In IT, it's always better to go with the devil you know, than the devil you don't.
As someone that programs as well, giving admin access to programmers generally makes sense. In a perfect world however, I'd rather give you your own sandbox to mess up and not your desktop so that when the next wave of patches get pushed out, I don't have to worry about your box not being like everyone else's because you altered the 'expected' state of the desktop the patches / configs were designed for.
Sans perfect world, as long as set ground rules are in place, any reasonable IT person should be ok with this request.
I think you would find that to be simply not true depending on the nature of the organization. Work for the government, or any security conscious organization, and you'll see how little control you have (for good reason).
There are terrible IT people out there, that's for sure. Many don't go beyond the knowledge of someone from the Geek Squad. But then again, that goes for every profession.
Many times the nicest IT staff are those that are the most clueless and have to make up for their lack of knowledge with personality. The cranky IT people generally have too much to do, not enough time to do it, and are stuck dealing with trivial issues that stop them from getting to the critical ones their jobs (or the company's uptime) depend on.
I think your experience has been very unique (and fortunate) to come to the nice = smart conclusion.
Some excellent points I hadn't mentioned in my reply in this thread. People often forget that keeping things up is a constant battle.
Your opening paragraph says it all though. When developers talk about how difficult programming is, I always explain IT like this:
"Imagine you have N sections of code you have to support that someone else has written. They may/may not be documented, whatever documentation you have may not even be accurate, you can't change the, and somehow they have to work together even though they probably weren't designed to do that. Oh and there's a good chance there's no one to call for integration help, but you're responsible for tactfully explaining this all to executives & end users without ticking them off, even though they'll only call you when it's broken."
It's too bad that the perception around IT's role has only gotten worse now with the cloud.
I agree 100% with this statement, but as someone that's lived in IT all of my career, I believe there is one more point: education. The most successful organizations have an executive team that embraces IT as a necessary component of success (rather than evil) and communicates that to the organization. It's the purpose & perception of IT that causes bitterness and wrong expectations in the workplace, on both sides.
Just look at the fact that no one ever calls up IT thanking them for dial tone 364 days in a row without incident, but many will complain incredibly that ONE DAY it occurs for 10 minutes, it's no wonder there is such a disconnect.
While you might be able to link this situation/behavior to any support role, I would respectively disagree. Most support personnel are clearly disconnected from the activity requiring support, but with IT you often are interacting within 0-2 degrees of THE person responsible for your issue. This dramatically changes the dynamic of conversations.
IT people (just like anyone else) want to be appreciated for their work, in part because they typically sacrifice more personal time than any other department due to the nature of their job, without a reflection in compensation.
Assuming the IT staff are competent at their job, once people begin to embrace that department, and not talk to them like Dell tech support, then perhaps the stereotypes will start to change.
Incidentally, the reason that the IT staff may be so pleasant to deal with at Google may have less to do with IT, and more to do with the attitude & intellectual level of the user base.
It's interesting how the criticism of supporting those that serve usually come from people that have never enlisted.
Anyone that has served in a war deserves total respect for the sacrifices & suffering they endured every day, regardless of the ethics of the cause. All war is bad, not just those we think are 'worth it', so either give soldiers the respect they deserve every day or be quiet, because many of the liberties we personally enjoy (not just in US, but every country) have come through countless lives, right or wrong.
I realize it can make you uncomfortable, but I'll never stop thanking soldiers in uniform for standing in to defend our country so that I don't have to. Thank you.