> "Taking 1.6 seconds, the process of opening and closing the car via an app is up to six times faster than before. In addition, efficient cryptographic encryption takes place."
A remote car key. You've invented a remote car key.
414 karma · joined October 12, 2016
A remote car key. You've invented a remote car key.
Disclaimer: Purely conjecture on my part. No particular knowledge of patent law, and only a high level understanding of the pagerant algorithm.
It wouldn't need to be expensive either to keep the servers running. There would be no flashy advertising displaying links that you would never click anyway and there be no sneaky algorithms trying to maximize your clicks or your attention since that would no longer contribute to the company results.
Everything would be far simpler. Getting there is less simple.
For the search to work, it should make an effort to get to know you, that is, try to track which pages you have previously edited or opened, or maybe it could access information about which project you are currently assigned to in JIRA or which internal repositories you have recently committed to in git. Also, which pages are popular, which pages are mainteined, etc. This would enable its search engine to filter bubble you and provide far better results that I currently see Confluence doing.
Further, it should be able to contain pages which are just indexed mirrors of other resources. Some pages could be simply uneditable mirrors of markdown files in your repository, making it possible for developers to keep documentation alongside the code if this makes more sense to them. Other pages could be mirrors of Word documents or Excel sheets of PDF files on shared drives or where the company likes to keep this stuff. All of this stuff would be thoroughly indexed by the wiki and would show up in search results.
So I guess what I'm proposing is that wikis become an aggregator of information more than a single store of information. And that they really, really nail the search part.
Personally I've come to favor keeping the technical documentation close to the code. That is, keep it as markdown files and check it into git. They are just as easily hyperlinked to as a wiki page on the bitbucket web interface (or whichever system is used). The main README.md should contain information on how to set up the dev environment. Other README.md files, located in the folder root of modules, provide more specific information.
Documentation of a less technical nature may still find a natural home in the Wiki, since we also need a place where various managers, testers, salespeople, support people, etc. can maintain their documentation.
They have also contained large amounts of information from separate projects, none of it which was relevant to my task at hand, and on top of that they have contained a wasteland of obsolete pages, the contents of which was trusted by no one.
I don't have a problem with the concept of a Wiki per se but I do have issues with treating them as a magical virtual haystack on top of which you can shovel information and from the midst of which you can painlessly extract needles.
Apart from the checklists, which people tend to skip, most of it makes sense. Running everything through a pull request is a good example of something which slows down the process but which is still worthwhile IMHO.
That being said, I really dislike when too many of these constraints are enforced by the technology. In coding, like in driving a car, there are times when common sense overrides traffic rules. Sometimes, even in the best and most diligent teams, the build server turns red. In that situation you just need to quench the fire ASAP to keep it from spreading. You don't want to create a task in JIRA, you don't want to create a branch, you don't want to involve your colleagues in pull requests, and you don't want to wait for a hour for unit tests to pass. You just want to apply the simple fix or revert the commit.
And that's why I prefer moderate social pressure over some algorithm enforcing stuff. A good team will know why the rules are there, they'll be professional enough to stick to them 99% of the time, and they'll also be professional enough to break them the last 1% of the time.
A bureau helps me out finding contracts so I spend very little time on self promotion. Also, I don't spend more money on equipment than I would otherwise have done (although, with tax deductions and all, I buy nicer equipment these days). Income tax is unavoidable either way.
I'm charging market rate, which is about 1.5x to 2x what I would get in a regular job with the same amount of vacation and sick days. On top of that, the bureau takes a cut, the details of which I don't know (I invoice them, and they invoice the customer).
On the negative side, being a freelancer is less secure and I may lose income between contracts. This hasn't happened to me yet, and in the current job market, it doesn't feel like an overhanging risk. I think the pay compensates.
Disclaimer: Danish job market, YMMV
I could imagine, on the other hand, freeloader countries like the Cayman Islands adding cryptos as a supported way of stashing away money. Thus, they could become a gateway between the legit economy and the crypto economy in the same way that they are already a gateway between the legit economy and money raked in by tax evaders, drug lords, and dictators. Thing is, the crypto part doesn't really add any value to their offering. And the real question with respect to Cayman Islands etc. is why we don't simply outlaw bank transfers back and forth from these places.
I guess the rule of thumb is to write code to most clearly express the intent of it. Often harder said than done but a good goal to strive for.
I guess there are always ways to circumvent these government regulations and put your money in an online casino in Barbados or whereever but it takes a special kind of person to want to go through the hassle.
In very much the same way, governments could choke the flow of real money in and out of cryptocurrencies if they wanted to. They are probably planning to do so but it hasn't been on the top of their priorities just yet, the crypto bubble being more of an annoying mosquito than a threat to the economic stability. A government crackdown won't mean that crypto currencies will go away but it will be obvious to everyone that they'll forever be RPG play money, and only a small amount of enthusiasts will want to hold them. Prices will adjust accordingly.
On a side note, I've noticed that a lot of crypto people are pretty obsessed with the USD value of whichever cryptos that they may own. "Make fun all you want, my ROI in 2017 was xx%". Well, good for you, and happy that we have now established that you still use real money to measure value, and that you are in it for the short term profit, not for some abstract, idealistic purpose.
It's stupid while it lasts bit fortunately it won't. Bitcoin has no practical utility, neither as currency nor as a store of value, and you can't pick the blockchain apart to extract anything of value. Bitcoin is like my dad's books of completed sudokus: Proof of hard work but not of any value to anyone.
ATM Bitcoin is approaching the $10K mark from above. The press will soon be writing stories about people who lost this-and-this-much. The stupid money which fueled the bubble will dry up.
Also, type definition hell is definitely a thing. Trying to match types to code often makes me feel like trying to match subtitles to a movie. Off to podnapisi, pick what looks like the best subtitles, fire up VLC, oh shoot, subtitles are ten seconds off, timeshift subtitles to match, watch movie until we reach the first director's cut scene, now subtitles are off again and wife in open rebellion. Which is probably the main reason that we subscribe to Netflix these days instead of trying to bootleg our way through. I'm digressing.
Anyway, it seems to me that after they started adding typescript typings to npm, everything has become more sane. At least for the more popular libraries, I rarely run into typing hell anymore. Less popular libraries, yeah, sometimes there is no typing, or sometimes the typing may still be off, but then I just give up and use "any". And these cases seem increasingly rare.
According to the Civ1 tech graph, which I consider the authoritative resource, they just need to develop philosophy and writing in order to research religion. They definitely got the writing part nailed. Also they are dabbling with philosophy. I think they'll make it.
On a slightly more serious note, some people (yep, I have read Sapiens) would argue that religions, ideologies, and corporations are all variations of the concept of shared belief systems. That is, the human ability to collectively make stuff up and pretend that it's real. Thus, corporations and religions are more or less the same thing. It's an interesting way to look at it IMHO.
It would all work nicely until the spammers start creating their own bots to keep our bots busy. Bots would keep inane conversations going forever.
Then, I presume, Skynet.
No matter what, they'll not be able to exchange all of their imaginary wealth to real wealth but they'll definitely make a killing. Unless they really intend to go down with the ship which would be poetic in its own way.
Um .. no. It will make code execute faster but it will be more work to write and maintain.
For most of the daily bread-and-butter code that we produce, speed is not awfully important but clarity is. In this equation, you gain a great advantage from stuff like garbage collection, functional programming, and a well equipped package manager, i.e. Javascript is a pretty good choice (and Typescript an even better choice).
On the other hand, if you're writing very specialized algorithmic code which will be executed a very large amount of times, then WASM and fine tuning is in place. As cool a technology as WASM may be, a very small fraction of our code is like that.
My prediction is that WASM will find its place, mainly within some of the more popular libraries available on npm. If there is anything to gain from rewriting, say, parts of ReactJS in WASM then it will eventually be done. But it will be totally transparent to the user of said library.
Taking a view at the server side landscape is also instructive. There is a plethora of languages which execute faster than JS, yet nodeJS thrives. So it doesn't seem like people are eager to ditch JS. Hater's gonna hate, of course.
I don't think it would be practical to enforce, nor necessarily very fair. Would we want to, say, drag the coal miner into court over his personal contribution to global warming? The world is a tangled web of externalities and none of us would be in a moral position the throw the first stone.
That being said, there is definitely a void of responsibility in social media.
Traditional media is a useful frame of reference. Let's say that some journalist invented a totally bogus story involving a pizza restaurant, a child-sex ring, and a number of named persons. I think this journalist would be hard pressed to get this past his editor and into print, and with good reason, because the editor is responsible for the validity of the newspaper, and so is the newspaper itself. The most likely outcome would be a lawsuit which they'd lose big time.
Back to social media. Let's have a look at Facebook. This is a tech company, not a media company, so they are not really responsible for their content. The users are kind of responsible but a lot of users are fake anyway so no responsibility there either. Behind it all are The Algorithms, and The Algorithms are not really responsible either, it's just convoluted AI type stuff which no one really understands. But let's rewind a bit. Is Facebook a tech company or a media company? Being a tech company is really convenient in terms of washing their hands but should we let them get away with it? Or should we redefine them as a media company and let them own the responsibility of the content which brings in users and ad money? Could the buck land in any other place when you think about it? Sure, it would be a hassle for them, they'd have to employ a lot more people to monitor and moderate content, they'd need to put mechanisms in place for better validation of identities, and they'd be less profitable. But that would be their problem to deal with. Free passes are not always forever.
There is a great irony in the fact that cryptocurrencies are designed to be finite in size to ensure their value, yet the number of potential cryptocurrencies in the world is pretty much infinite.
Well, fast forward to 2017. MacBooks are all over the place. And when trying to shut down Windows 10, I'm faced with just three options: Sleep, Shut down, and Restart.
Vista really was the nadir of Microsoft in terms of UX, no matter how furiously some people contested this back in the day. And Joel was spot on.
If you see design patterns as indicators of language smells -- and it's a useful perspective IMHO -- then in this case callbacks were the smell and the various promise libraries were the design patterns. It's a nice thing that promises and their async/await sugercoating have fairly rapidly made it into the core language.
Now, for the one thing that I don't like about async/await: it's deceivingly simple and it's bound to fool both novice programmers and programmers arriving from threaded languages. If you don't understand the underlying concept of promises, you'll easily end up writing suboptimal code (e.g. executing stuff in sequence which would be better executed in parallel).
Still, a net win.
The whole story thus boils down to a nice, illustrative all-other-things-equal experiment of how off-the-grid self sufficiency stacks up against a renewable energy power grid "done right". The latter winning by a large margin.
That being said, there are plenty of sunny places on Earth where the power grid is dysfunctional, or is hard to access. Those would be more obvious places for DIY solar panels.