29 karma · joined July 4, 2015
Obviously you have an inside perspective that I don't, but from the outside it just looked like y'all made an amazing phone. :) I can't say I heard much about internal issues, but I believe it given other things I've heard about Nokia internal management...
Did you ever use an N9? It was nothing like that.
The 770 tablet, and such, sure. But the N9 was quite far removed from the geek toy tablets.
I think that's kinda revisionist history.
Maemo was already developed by the time the phone market turned into the software-driven smartphone market.
Nokia was late to throw Maemo on a phone, true, but they had one ready in 2011. It had hardware that won all sorts of design awards and was cutting edge in both hardware specs and design, with classic Nokia durability and engineering. It ran a wonderfully-slick, open-source friendly, polished OS. It even had a "Retina-level" display before they were common. Nokia still had a major marketshare when it was ready for release and could have used their market presence to ensure a successful launch.
The problem was, Elop was trying desperately to kill it.
He couldn't quite kill it outright, as Nokia had contractual obligations to release it, but he ensured that it got minimal advertising time and prevented it from being distributed in many key markets. Despite that, people loved it. It swept design awards. Some reviewers called it the "best phone Nokia ever made." People in EU countries where it wasn't released were buying it via eBay from the countries that did have it.
Elop's response? No matter how successful the phone was, no matter how much people liked it, Maemo would never be used again.
Naturally, the aggression towards the platform by the CEO coupled with the limited release and minimal marketing did just fine to kill it, and he was free to continue molding Nokia into a target for an MS buyout.
Nokia understood the market just fine. They were just betrayed.
BlackBerry under the previous CEOs was much like Sun: lots of cool ideas, lots of smart people, but no direction towards shipping products people wanted.
Now it's like Apple shortly after buying NeXT. Only with no advertising (their current biggest flaw).
One good question to ask yourself when evaluating a framework is this:
If the project/company dies out tomorrow, and we're tied to this thing, can we take it in-house and pick up maintenance?
If the answer to that is no, not even long enough to migrate to something else, then boy, you'd better be damn sure that the team that develops it isn't going to go away or lose interest. Hence my skepticism with many, many Javascript "framework of the week" projects. There's just far too many out there that have died out after a year or two for me to blithely accept whatever the new hotness is.
I've written plenty of stuff under the BSD license which has been distributed with and without modifications in tons of commercial products, rarely with source. Totally fine, and exactly as I intended.
They're not really comparable.
This is code generation for builders, getters, etc. The idea is that you write less of the boilerplate that you'd write if you were rolling your own immutable POJOs.
Plus, unless I'm mis-reading the docs, it also handles certain collection types transparently. (Which obviously just throwing final on a property won't do.)
Yes, and years later BlackBerry is still around, with a CEO that's almost finished reversing the damage the previous ones caused.
I get your point, but still. Also, you seem to be conflating stock price with company success, health, etc. You shouldn't. Post 90s, they're pretty divorced from one another.
> I think they're saying bye to relevance and innovation. They're worth half as much as Tesla, for example.
No, they're worth half as much as Tesla according to the stock market. There's a big difference.
It's how it's ended up in JS that I'm not a fan of.
Handling abuse complaints, wrangling bandwidth spikes, etc. ended up taking way more time than I wanted to give to it. This was before a lot of the modern easily-scalable hosting services were around, so it's not like I could just automagically spin up new instances.
So basically, I ran out of time in my day, and since I already had a good day job I figured "fuck it" and sold out.
I maaaaaybe could've gone full time with it, but it would have been really hard and I would have been competing against some already well-established players. I didn't have much presence outside a particular community, and growing it into a general-purpose thing would've probably killed the "one of us" karma that let me get popular in the first place... so... yeah, not a good plan.
> 2. how did you get out of it? sold, fizzled, etc..
Sold. The party that bought it promptly ran it into the ground in a rather impressively stupid series of decisions, and it was gone within a year. Oh well. Not my problem. I got a decent payout, which -- being younger and stupid -- I promptly blew. So basically in the end all I got was a year or two of really fun living. :)
I'm actually OK with that. It didn't start as more than just a way to serve a specific community's needs, it blew up in popularity and as a result I got some cool experience and some spending money out of it. Seems like a successful project in retrospect.
Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
Yes, there are funds that try to match the entire market. Vanguard runs a couple "total market" indices (VT and VTI, for example), and there are more.
But that's not to say that they actually invest in the entire market. They don't; they use sampling to try to match the performance of the thing they index. (Vanguard, at least, gets very very close to this...)
Disclosure: I am invested in in VTI.
Yes, but it's worth noting that the increased risk of heart disease from smoking is due to more than just nicotine.
... so imagine my surprise when I received an e-mail (at the abuse@ address, no less) offering to buy uploader/downloader info (IPs, file info, email addresses, etc.)
Imagine their surprise when I told them that I didn't have most of what they wanted in the first place, and that they could kindly go suck a pig. I checked out the company in question, and they seemed rather sparsely established, so my assumption was that they were a shell company for somebody. Never really looked into it after I told them to go to hell, and never heard back from them. AFAIK there wasn't a lot of pirate traffic (I shut that down and banned/reported aggressively whenever I found it/was notified about piracy or other illegal stuff), mostly just niche content that I assume was original... so I doubt it was an MPAA/RIAA thing. Odd.
(Sorry for keeping names out of it. The site was super well-known within the community, and I'd rather keep my involvement in said community quite isolated from my real life.)
Glad to be out of the file host business, that's for sure.
No disagreement there. I just meant that you don't need to start from a blank canvas and start in on engine, editor, etc. development just to get to the point where you can do good game mechanics. Obviously even if you use a canned engine you'll still need to do some work to get your asset pipeline squared away (just as how everyone needs to do a bit of scripting/config, etc. specific to their build process for example.)
I guess I didn't explain it well, but I was trying to contrast to the web world where people [seem to] very often look at places like Facebook rolling their own frameworks and saying "we need to do that to be good!" and thus literally go on to start from scratch.
That's one approach, but it's not always the right one. It's only really necessary if your studio's selling point is pushing the limits, tech-wise. If your focus is the gameplay mechanics and engine and art are secondary to that, then focusing on tooling is more of a distraction than anything else. Hence why Unity and the now-quite-cheap UE are sane choices, since they let people focus on the gameplay.
General purpose software has the same pitfall that games do: people see the big studios/development companies spending a lot of time on tool-building, and they assume that's a prerequisite, which changes the mental model from "we need to start building the next cool _____" to "we need to build the tool(s) that will let us build the next cool _____". And that's a much more expensive model.
I think it's easy to get sucked into that trap for another reason too: developers know what developers want more than developers know what users want. That's why I agree with the last paragraph you wrote, that user involvement is key. I just think that companies need to be careful that they're not simply redefining users from "users of our core product" to "developers of the tools that will let us build our core product", since there's going to be some natural internal bias that way.
Well... cod liver oil, actually. And that would be here: http://store.chriskresser.com/
Frankly, I wouldn't put a whole lot of faith in either.
There's also the lovely condescension that I can't help but sense when someone tells me why writing code every day shouldn't be as fulfilling as it is. That's a big part of how some people get a sense of fulfillment, myself included. I suck at drawing and painting, and programming is my main creative outlet. Implying (or sometimes stating!) that I should be spending less of my time coding so as to spend more time doing something that they find more fulfilling is... rude at best.
On my team, the long-standing rule is that you need to make a best effort to stick to the module's existing style. So we're not gonna bust your balls because you don't split at exactly 100 characters or whatever... but if you never wrap your lines and if you insist on indenting things completely differently than everyone else then yeah, you're creating a problem.
It also helps that our "style guide" is pretty minimal. Brace conventions, indentation, spaces before conditions, etc. Things that have a serious impact on readability and ease of debugging and that can easily be auto-formatted. What we don't specify is the higher order stuff -- provided you are internally consistent. We don't mind if API A uses one naming scheme and API B uses another, provided that we don't have a mix of different ones in the same API. Same for how something like object extension is handled. This falls into the realm of "we assume our developers will make the best technical choice", but so far it works.
There's always a complaint that specifying the braces, spacing, etc. is stupid, and if it required a lot of human intervention or was treated as a serious offense I'd agree. For us it doesn't, and it's not. The purpose is to limit the amount of visual friction when switching from one file to another. What the code is doing is the important part -- presentation should be as uniform as possible to limit distraction. Add in the fact that we've got an Eclipse profile with all the spacing, etc. setup the way that we do it, and it's pretty easy to keep things tidy.
For visual parsing, consistency matters. In an object literal dec I expect:
name : value
nameandvalue(){
I'm a little too sleep deprived to think through this entirely, but just off the top of my head, it seems like over the course of a few frames that an edge in motion would wind up as a series of triangles where one of the points remains static while the other two shift away from it -- in other words, the Trigrad approach would yield motion blur as an artifact. And then when the next key frame comes along, the remaining point gets reselected, probably further along the motion path... So much like a normal differential approach you wouldn't need to store all of the point locations each frame, just the ones that change and which triangle they belong to.
It might be hard to make it stream-friendly though, since obviously the compression efficiency depends heavily on the storage structure (see pjtr's comments)...