ozataman
For example, you may need to provision a 20-node cluster only because you need the 10+ terabytes in storage across several datasets you need to keep "hot" for sporadic use throughout the day/week, but don't nearly need all that computational capacity around the clock. Unlike BigQuery, Redshift doesn't separate storage from querying. Redshift also doesn't offer a practically acceptable way to scale up/down; resizes at that scale take up to a day, deleting/restoring datasets would cause lots of administrative overhead and even capacity tuning between multiple users is a frequent concern.
Making matters worse, it is common for a small number of tables to be the large "source of truth" tables that you need to keep around to re-populate various intermediate tables even if they themselves don't get queries that often. In Redshift, you will provision a large cluster just to be able to keep them around even though 99% of your queries will hit one of the smaller tables.
That said, I haven't tried the relatively new "query data on S3" Redshift functionality. It doesn't seem quite the equivalent of what BigQuery does, but may perhaps alleviate this issue.
Sidenote: I have been a huge Redshift fan pretty much since its release under AWS. I do however think that it is starting to lose its edge and show its age among the recent advances in the space; I have been increasingly impressed with the ease of use (including intra team and even inter-team collaboration) in the BigQuery camp.
There is something potentially harmful, or perhaps that needs addressing, about end-user tools growing in expressive power. A good friend who does statistical genetics work once told me "but I don't want every user running their own regressions and drawing nonsensical conclusions from badly prepared data!"
Don't forget that, from the manufacturer's perspective, Amazon is not only the logistical facilitator, but also a sales channel where huge numbers of potential customers are introduced to companies they wouldn't naturally be exposed to.
They play thousands and thousands of hours and, yes, also spend quite a bit of time reading, thinking, analyzing (both their own and others') games and learning from mentors/teachers. However, practice is king and all the reading/analysis would be worthless in its absence. They would have no anchors to grab onto in your brain - no way to really become operational.
A chess "player" that mostly reads, studies and analyzes with a little bit of practice sprinkled in between would indeed be hilariously weak.
Soostone is a technology provider in the enterprise analytics space with a focus on performance improvement for e-commerce clients. We are the developers of a highly scalable platform that revolves around data, modeling, machine learning, real-time decision-making and sustained optimization. We routinely build features or capabilities that make use of in-process and multi-node concurrency, parallelism, stream processing, domain-specific languages (DSLs/EDSLs), Functional Reactive Programming (FRP) on GHCJS, MapReduce on Hadoop (via Haskell) and many other methodologies common in the functional programming world.
We also care a great deal about contributing back to the community by open sourcing useful components wherever possible. Our team members help organize a number of community events in eastern United States including the monthly NY Haskell Users Group, Hac NYC and the Compose conference.
If interested, please submit applications to [email protected]
Website: http://www.soostone.com
It is common to hear in the Haskell community remarks like "Haskell is the best imperative language I've used."
Cassandra et. al. are completely different, in that you don't use them because they are more fun to use. You use them despite their awkward, low-level interfaces because you're going to dump billions of data cells into your database from day one with no end in sight and want all the easy scaling/availability features provided.
- Smaller fonts and less obvious icons on the weather app
- Less info on the world clock without the digital time text, which helps grasp the time at a glance especially when you're looking at several zones.
- Smaller direction character font on the compass (why would anyone do that? It's like 40% of what it used to be and is only a single char!)
- Less contrast across the entire interface with all white text; harder to discern differences.
... and at best a neutral change across the others. I haven't yet installed it myself, but the screenshots look disappointing. I am not dismissing the idea of removing skeumorphisms, but this particular implementation/execution seems like a step in the direction of less refined for Apple.
I have seen very few screenshots so far that made me say "oh that's so much better, wow". Several did make me say "Gosh, why would you reduce the font size there?!?! Why would you make the icon much less obvious?"
Just to note that I am not trying to be negative - I am certain with this much solid engineering talent, there will be features we'll love.
I hope I'm proven wrong once the OS is officially out and we're hooked in the following few weeks.
- https://github.com/tibbe/haskell-style-guide/blob/master/has...
- http://stackoverflow.com/questions/6398996/good-haskell-sour...
Edit: And then of course actually use the prominent guidelines for good-looking code in each language!
over (location.x) (+ 10) $ player1
"over location's x, add 10"
Know that by doing this, you may be counterproductive both to your organization and your career. If you take it to the extreme, you may become a friction rather than a "problem solver".
The most common pitfall I've seen is a highly technical person considering things like "refactoring", "getting it right" more important than getting to the finish line fast. Remember that you may be missing what's really the most important thing for your company at the time.
I've also seen commonplace "complaining" about inconveniences that are actually quite legitimate. It's just that you don't know all the facts or haven't been put in a position to produce the bottom-line results. Things look different when you're the one navigating the ship.
OTOH, I've seen this strategy work best when the very formal scope/objectives/deliverables of an effort are clearly wrong and would indeed lead to a subpar outcome for all involved. Implemented successfully, this strategy could produce outstanding results by forcefully course-correcting and then actually delivering great results. Remember though that you'll be blamed for everything if your course-correction isn't great, even if the original direction would also have been equally bad.
Thanks for posting this!
If we have to impose a timeline, though, I would say that all 3 elements (market fit, strategy, biz model) have to be considered together, all the time in the leaders' heads (and officially recognized once in a while). Please remember that there is only a single digit (or so) number of Twitter-like stories in the world. Just think of the numerous times that kind of linear thinking (forget about biz. model - let's just pour money into this thing for a long time, or, let's build this cool product without a strategy although I don't even know what cool means without a strategy) approach has failed. In those rare cases, you probably still think about the biz model, as in "it doesn't yet exist but will exist likely in one of X forms once we reach status Y".
I might have a different definition of strategy, but you need some kind of strategy, which at a high level might even just mean "approach", to be able to do anything, including validating an initial market fit. Even starting small, testing/iterating and seeking market fit and later switching gears itself is a form of high level strategy. A ship without a direction gets nowhere, even if you're a small ship in a really-well charted sea.
Unless, of course, he means by product-market fit "an idea for a product/service that the market wants", which would be just about the first thing to do in any business, as championed by the likes of the book "Four Steps to the Epiphany". I suspect those bootstrapping (to at least some degree) would likely know this from deeper in their hearts than others who've had an easier time with plenty of funding upfront. Everything else by definition has the workings of a strategy, whether you admit it or not. If you're not explicit about it though, you're just letting the waves take you places you hope will be good.
Edit: The issue I take is that the article puts strategy into a step in the timeline or process, whereas I believe it needs to be everywhere, all the time. You can't have product-market fit without strategy AND/ORD you can't build a solid, sustainable business without thinking about strategy/market-needs/biz model and probably more at the same time, holistically throughout your existence. It's not just that "don't forget about strategy before biz model!!". Jumping to biz model without having a strategy is impossible - it just means your strategy implicitly is to "grab the money in the best way you see possible right now", without charting a longer term objective.
As for other reasons:
1. It leaves a bad taste in your customers' mouth. Security should be an option.
2. Imagine the disaster if someone makes front-page on HN complaining how their PW got snooped and their top-secret project plan is now public.
Pay-for-SSL was a bad idea back in 2005 - now it's a non-starter in my opinion.