This is just a guess, but reading RFC 819 (https://tools.ietf.org/rfc/rfc819.txt), which transitioned ARPANET to a hierarchical naming scheme and also predates DNS, the little-endian notation might be a simple artifact of ARPANET's e-mail addressing. E-mail addressing was already user@host, which is basically little-endian. It would be consistent to extend it like user@host.site.network. JANET also used @ notation, but used big-endian notation for the domain, which seems inconsistent, at least from a user's perspective.
Wikipedia says JANET's e-mail addressing notation was defined by the "Grey Book", and this Usenet thread, http://neil.franklin.ch/Usenet/alt.folklore.computers/200209..., says the Grey Book domain notation comes from the Network Independent File Transfer Protocol (NIFTP aka "Blue Book", which was a different protocol from ARPANET's RFC 354 FTP). This 1990 JANET<->ARPANET e-mail gateway document, http://dotat.at/tmp/JANET-Mail-Gateways.pdf, says that JANET e-mail was transferred using NIFTP, so it would make sense that the domain part of the e-mail address would use NIFTP rules. Both above sources say (explicitly or impliedly) that JANET generally, and NIFTP specifically, were based on X.25, and X.25 uses big-endian addressing.
So on JANET the hierarchical naming scheme predated the e-mail addressing scheme[1], whereas on ARPANET the reverse is true. Both formats make sense as path dependent outcomes.
[1] Presumably JANET still adopted user@ because the message format was based on RFC 822, according to that gateway document above, but it was still worth partially deviating from RFC 822, which explicitly defines little-endian domain syntax, because of JANET's pre-existing host addressing scheme.
I am still waiting for an apology for mathematics and base 10 numbers being written the wrong way round logically!
Same with SQL. I am giving SQL trainings this year, and I have to explain why the server will read your query in a completely different order than how you write it.
Numbers are written correctly, most significant digit on the left. SQL is mostly correct according that logic, first `join` then `where` then `order by`. There are inconsistencies though.
You are used to see the most significant digit on the left, but really we have to right align a column of number in order for them to be readable, whereas everything else we read is left aligned. And you don't know what this significant number corresponds to (thousands, millions, billions?) until you have read all the other numbers (if you read left to right).
As for SQL, you write
SELECT TOP 10 ColName FROM TableName WHERE X = 10 ORDER BY ColName
and the server reads
FROM TableName WHERE X = 10 SELECT ColName ORDER BY ColName TOP 10
It is not "mostly" the right order.
And right to left assignment for mathematics or programming.
I suppose an enterprising browser hacker could implement this such that the browser could accept URLs in this format and reorient them when it makes the requests. Even paths would be tab-completable from browser history, would they not? I would love this in my browser.
That's actually how addresses are written in Chinese -- most general to most specific. Super disorienting when you're learning it as an English native speaker.
Cloudhealth Technologies (www.cloudhealthtech.com) is the leader in cost usage and reporting for the cloud and on-premises infrastructures. Cloudhealth is transforming how businesses save money and take control of their infrastructure.
Our stack is a mixture of angular, ruby, java, scala, and spark with a lot of interesting data engineering and data analytics problems to face. We're migrating to a microservices model using kubernetes and kafka as a bus for services.
Please let our recruiter Dave Aquilino (davea@cloudhealthtech.com) if you're interested, and he can follow up with you!
Cloudhealth Technologies | Software Engineer | Boston, MA | Onsite
Cloudhealth Technologies just closed our Series D round of $46M. We're the leader in cost and usage reporting and optimization for AWS, Azure, GCP. We've recently GAed a product for Datacenter, too.
Our stack involves ruby, java, scala, spark, and angular. We've got thousands of customers worth of data and interesting problems to solve.
* Do they have their own projects or do they contribute to others?
* How interesting are those projects generically and in the context of what I would need this developer to do?
* Are these projects actually used by anyone? Are there pull requests, etc?
* Does the developer actively keep working on existing projects or move around? I.E., are these learning vs hobby vs commercial?
* How is their readme? Does it exist? Is it sufficiently complete to convey meaning?
* How is the code organized? Is it reasonably laid out? Do they make use of third party packages and tools? Does it seem like they are re-inventing the wheel?
* Does the code work?
* Is the language chosen the right language for the job? Are they using idioms of that language or more generic ways of expressing loops, vsriables, etc.?
* How extensible is their design? Does it feel krufty or is it a pleasure to read?
* Is the code novel? Are they re-inventing the wheel or are they actually fulfilling a need?
* Are their projects wide and varied in scope and tools?
Those are a few things off the top of my head. Not an exhaustive list.
As long as you understand idioms, programming paradigms in general, and good patterns in specific languages (e.g. list comprehension in python, prototypal inheritance in js, metatables in lua, etc.) you shouldn't be afraid of showing off your stuff in X language.
I know good Java developers that have become really good front-ends.
Well Java doesn't have a stigma attached to it like COBOL or BASIC does. What about those of us who have terrible QBASIC code they wrote when they were 14 on their github/bitbucket/etc profiles? I'm not going to hide that; it's public because it's useful. (I intend to dig up more terrible code I wrote and put it up)
Cloudhealth is the leader in infrastructure cost and usage optimization. Our products span across AWS, Azure, GCP, and Datacenter. We do the heavy lifting of analytics around what your cost and usage means split across business units, regions, availability zones, time, and many other dimensions.
We're working with spark and EMR to process terabytes upon terabytes of information. We have a ruby-based application layer which presents to angular, and we're rapidly ramping up our development team to make major improvements to our platform.
If you have a passion in backend or frontend engineering for improving small to Fortune 500 size businesses, Cloudhealth could be the place for you!
We offer all the usual perks of free stuff, food, commuter benefits, and otherwise. The engineering team here has a lot of engineers who have been working in industry for decades with a combination of less experienced software engineers creating our next generation environment.
Please feel free to email me at johnm at cloudhealthtech com if you're interested!
Cloudhealth enables company's to take control over their cloud usage! We're the leader in programmatic cost management and a provider of resource monitoring to help identify areas where our customers can improve their infrastructure.
We're looking to hire developers of any experience level that are dedicated to taking on complex challenges in a fun, upbeat environment.
The Bureau of Labor Statistics (http://www.bls.gov/) is just fascinating enough and just badly organized enough that I never seem to be able to get to the same useful piece of information twice. And thus I constantly find myself looking at other interesting facts about the US labor force.
As an intern project years ago I had to all the BLS data into a database for analysis. Any time I ran into an issue I would call them directly. Little known fact that every BLS data set has a source.txt file with a phone number to call. You might think of government agencies as massive bureaucracy, but I was amazed at how helpful and knowledgeable everyone I spoke to was (and that the calls were answered at all). They would answer my immediate question and often explained the logic that went into the data structure.
Making survey data structured is quite challenging and I gained a lot of respect for the work they do.
Anyway, if you go down this rabbit hole, maybe make it an IRL rabbit hole and giving them a call may help get to your answers quickly.
I know it was a younger time back in 2006, but there is always something disingenuous about referring to the entire class of software developers being unable to do good frontend UI/UX development. It's a different discipline to be sure, but it's not a lot different to me than saying knowing statistics to be a good data software developer or any other application development. Software doesn't get written for its own sake.
I am contemplating a move from Github to Gitlab right now. Feature-wise there seems to be enough parity with Github to make this sort of thing possible.
Also, gitlab's CI system is attractive and being able to run our own runners in our own environment (we currently used an outsourced CI system.)
We're also doing it because Github enterprise is too expensive, and we want to rely on less external dependencies in our environment.
Glad to hear you're considering to move to GitLab. We think being able to have CI Runners on your own environment too is a great advantage, not only on Linux machines but any. For GitLab.com we're using autoscaling runners https://about.gitlab.com/2016/03/29/gitlab-runner-1-1-releas... at Digital Ocean and we're running 2800 now, see http://i.imgur.com/8bP8QBh.png for a screenshot I just took that combines our Digital Ocean runners with people that bring their own.
