jodoherty

It doesn't make sense in the context of today's relatively uniform hardware, but I think the goal wasn't so much portably correct code, but portably efficient code that avoided the need to use assembly language for everything.

The first version of UNIX was written in assembly language for an 18-bit machine. C was invented as part of rewriting UNIX to work on a 16-bit machine and who knows what to expect after that. Machine architectures were a lot less uniform back in the day, and most of those minicomputers are easily beat by some of today's 20 cent microcontrollers.

Given that context, being able to loosely define relative data type sizes based on how efficiently they might be represented on the machine might make more sense.

But you're right, that's quite alien to where we are today.

By the 1980s, Ada was already making the right call of allowing the developer to specify the behavior and exact range of modular integer types for correctness and letting the compiler optimize things for efficiency or performance as needed. It'd be nice to see that approach become more popular.

Same here except these days I just use the print to pdf feature in Chrome.

DevOps and hosting side projects initially. I never approached full utilization (CPU or memory) with either one as a home server, so now I have a third Precision 7810T with 32 cores (dual Xeon E5-2698 v3 processors) and 32GB of memory that hosts all my side project infrastructure at home (in addition to my website).

Lately I've been doing distributed computing, machine learning, and cybersecurity side projects with them. I can run a variety of environments and tools while still using them to game or for everyday computer tasks (running several multi-core VMs is no problem with this kind of hardware).

I don’t think it’s worth paying a premium as long as you regularly checksum important data and look for changes over time, keep redundant backups, and regularly check for integrity failures. You should see the inconsistencies as an early warning sign. Just don’t set up your workflows so it’s too late by the time you see them.

That said, I’ve seen a not insignificant number of computers in the wild that couldn’t calculate valid sha256 checksums when utilizing vector optimized implementations. Who knows how bad other hardware issues could be. You just wouldn’t know. I would pay a little extra for ECC memory given the choice.

In fact, I have two Dell Precision T7810 workstations at home with 144 GB of ECC memory and dual Xeons totaling 36 cores on each machine as my two primary personal computers.

I like this idea a lot, personally. Separately deployed customer instances as an approach for “multi-tenancy” also eliminates the need for sharding databases at scale, since most of your scaling will just be new deployments. Overall, this suggestion has an appealing set of trade offs if you have the DevOps chops to pull it off.

Just watch out for really really big customer instances (but then they should be paying more than enough to spend time on their particular scaling issues).

Build and design for multi tenancy all the way down to your schema.

Keep identity and login mechanism decoupled - plan to support multiple login mechanisms per user (email/password, SAML, OpenID Connect, Google) for a single identity and multiple authentication factors (TOTP, Duo, etc). Be very careful to about what you consider a verified user and how you verify email addresses.

Use TLS even for your database connections. Use encryption at rest. Automate backups and plan to restore or export data for specific customers rather than the whole application.

Use a time series database or event logging system and create an audit trail of everything any privileged user does in your system, any account or permissions changes, destructive operations, etc.

I use the Kinesis Advantage 2 keyboard and the Logitech Ergo M575 trackball mouse pretty exclusively these days

Don't think in terms of tests -- think in terms of examples.

Write examples of how you would like to be able to solve common cases and handle edge cases if you had the ideal interface based on what you know at the time, then use unit tests with stubbed out interfaces as a tool while trying to develop the implementation.

Refine and even rewrite your examples as you learn about what works and what doesn't work.

Recursively break down complex pieces into smaller modules as you learn what can be handled independently and composed with the other pieces. Break off independent examples depicting how you expect those modules to work and be used as new unit test suites for those new modules.

Don't sweat testing the implementation details, especially when prototyping. What you want is to use tests as a way to speed up your development process and improve the quality of your design and architecture.

Try to write tests that show off how nice your code is to use and how few edge cases you need to handle when calling it. It'll raise the bar for how your code interacts with the rest of the application or system and give you smaller pieces to work and focus on.

Finally, for really green field stuff with a lot of unknown unknowns, you often have to write a lot of standalone, bottom-up throw-away prototypes for things. That doesn't invalidate the usefulness of tests, so don't be afraid to do that pretty regularly.

It would dramatically limit your attack surface to those who could gain access to your VPN.

I prefer requiring TLS mutual authentication with a corporate PKI and issuing employees client certificates.

Doing both wouldn't be a bad idea either.

38/40

I feel like I spent an entire decade mostly in contemplative reflection and observation as I searched for intrinsic meaning and purpose.

I imagine many others who score well have some similar period they've been through where it almost feels like they spent more time observing themselves and others living than actually living.

The key takeaway to me is that developing mobile apps for the Librem 5 on the Librem 5 is a first class development workflow.

This is great. Not having to worry about setting up toolchains on a separate platform, cross-compiling, and then signing/transferring apps and running remote debugging sessions makes it easy to just build and test apps.

WebDriver provides a standardized interface for automating web browsers. It makes building out automated cross-browser tests easier, since you can utilize all the browsers in the same way if they support it. It's mostly confined to use in automation and testing, not something a webpage would use with your browser as you browse the web.

Currently, the protocol is request/reply from the client to the browser, so if you do commands involving a page and want to wait for something to appear (a dialog, a confirmation message, a notification, a changed element, etc.), you'd have to check the page over and over again in a loop of commands to inspect the page's state to see if the change happened. This BiDirectional spec would allow you to execute commands that tell the client to send commands back when certain browser events or DOM changes happen, allowing you to specify a callback handler that happens when the event triggers rather than having to poll with a loop.

This makes implementing tests much easier and more consistent. One weakness of polling, for example, is that if something changes on the page and then changes back between your checks, then it'll appear as though it never happened. The BiDi spec makes it so you get events for the changes without having to worry about polling rates.

If you really care about user experience, I recommend seeking out products made by companies that are vertically integrated, like Apple, because they have the power to curate the components of their products for maximum compatibility and support.

The closest examples so far with Linux are System76 and Purism:

https://system76.com/

https://puri.sm/products/librem-14/

This is also what makes the Surface tablets and Surface Book so great. There's a top to bottom alignment of interest in creating the best user experience and making sure the product works.

The closest thing to computing hell is when a commodity operating system is slapped onto the cheapest commodity hardware by someone who isn't concerned at all about using it, but has a list a mile long of systems to configure. There are plenty of enterprise IT-managed work laptops with no display or chipset drivers that can't hibernate, but at least they have McAfee virus scanner installed and the corporate group policy enabled.

It's easy to criticize the chosen trade-offs, but I would argue that Linux would actually be in worse shape today if it had taken the driver ABI approach and encouraged proprietary drivers. Many drivers originally upstreamed in the 32-bit x86 era would no longer be usable on amd64 had they been 32-bit proprietary drivers, and a good number of 64-bit proprietary drivers would be useless on ARM platforms like the Raspberry Pi.

There are a lot of old computers in research laboratories running Windows XP because some proprietary driver for some important piece of equipment (like a mass spectrometer) doesn't have a 64-bit version.

It is, but the point of not defining a Linux ABI is to avoid proprietary, binary blob drivers and instead force drivers to exist in the upstream Linux kernel where they can be maintained by the kernel developers and freely distributed.

This has a lot of advantages of this approach over binary drivers in that:

- The driver can be updated so it survives architectural changes (say from x86 -> amd64 -> armv7 -> aarch64 -> riscv).

- The kernel can be changed freely without worrying about supporting drivers that cannot be updated because they only exist as binaries.

- Bugs in the drivers can be identified and fixed by anyone (most importantly, critical security bugs).

Also, good ABIs are hard to get right. Windows had to completely rewrite their audio subsystem and the associated driver interfaces around the time of Vista to get low-latency right, for example.

But that said, the use of binary blobs exists even today (CPU microcode, various driver firmware blobs that people don't have time to reverse engineer, etc.).

Someone else also mentioned ndiswrapper, which reimplements the binary interface for supporting Windows network drivers on Linux.

So you can pick any Windows driver interface and write a Linux kernel module or a combination of a kernel module and some userspace framework that can host and utilize that driver. You might have to emulate or paravirtualize some hardware access or instructions to avoid causing conflicts, but there's nothing technical stopping you, other than it just being hard. It can also never be included in the upstream Linux kernel for the ideological reasons I already mentioned.

Most hardware device vendors write Windows drivers and test them. Since they built the hardware, the vendor driver developers are privy to all the internals. Windows also has a stable ABI for drivers.

Hardware device vendors don't always write or maintain Linux drivers there's no stable driver ABI for binary drivers to be built and distributed for Linux. Instead, vendors are encouraged to write drivers that follow the conventions of the Linux kernel with no hardware abstraction layers and submit them for inclusion in the upstream Linux kernel under the GPLv2. Not every vendor is willing to do that (NVIDIA for example), but some do (AMD, Intel).

The major takeaway for me is that with a strongly held culture, everyone in the company is playing the game by the same rules, making it clear how to succeed, how to fail, and as such, how to conduct business. It's also clear whether or not you would enjoy working there -- there's no finding the right team or department with its own culture if everyone has the same culture there.

Of course, he doesn't explore whether or not the benefits of this are worth the disadvantages, and there's plenty of room for argument either way, especially with large organizations.

Give Go a try. It has a few unique conventions, but overall it strikes a nice balance between clarity (no surprises) and convenience. It feels like one of those languages you can fit in your head, idioms and all, kind of like C or Pascal.

I always fall back on this pattern when the return values need to be used further down:

  foo, err := doThing(bar)
  if err != nil {
    // handle error
  }
  foo2, err := doThing(bar)
  if err != nil {
    // handle error
  }

Only one value in a multi-valued assignment has to be undeclared to use the short variable declaration operator (:=). If the variable already exists in the current scope and the type matches, it will get reused.

https://play.golang.org/p/qo141lT-Jjp

Actually, VIM does support this. Type Ctrl+V in insert mode followed by whatever you want to insert (e.g. Ctrl+\ for the ASCII FS character). VIM will insert the literal value of the control code into the buffer.

Standard English dictionaries often don't have the precise definitions used in specific fields, which only leads to more confusion for laymen, but any good introductory Chemistry lab textbook should be able to get you up to speed on experimental science definitions.

Precision is how fine a measurement is (i.e. being able to measure temperature to thousandths of degrees versus tenths), whereas accuracy is a measure of how closely your results much the objective truth. So you may have a very precise thermometer that measures to thousandths of degrees but it may not be accurate because it's calibrated such that it always reads exactly two degrees higher than it should. Meanwhile a thermometer that can only measure to a tenth of a degree is more accurate and less precise than the one just mentioned if the shown figures reflect the true temperature.

In common usage, these words mean the same thing, but scientists often give words specific meanings in order to make their research and ideas less ambiguous.

Definitions are even more important in non-scientific fields such as philosophy or math where meaningful reasoning of abstract structures and ideas would be next to impossible without giving them concrete definitions and stating your assumptions.

Remember that definitions are arbitrary, so to understand an author's argument or idea, you must seek out the author's definitions.

Hopefully that clarifies some of the discussion going on in the comments here.

With plain HTTP, it'd be very easy for someone running an open WiFi station or a corrupt ISP to set up a DNS server that points the domain to their own reverse proxy that then can modify the page that the user receives to include some additional JavaScript to forward the user's password or the decrypted page results after the user inputs their password.

This doesn't require compromising any servers, and a lot of laptops will configure their DNS settings based on what the local network's DHCP server sends them.

To the end user, it will appear as though nothing is wrong.

I've used the `co` library at work to extensively trim down and simplify a lot of server-side Node.js code recently. It's worked out very well compared to the very Promise heavy code we had before, especially since so many database libraries now make use of promises. I would highly recommend it if you're going to be stuck using Node v6 for the next 2-4 years.

On the front-end, we're using TypeScript 2.1.5, so we've been able to make good use of async/await there. The only tricky parts are dealing with AngularJS, due to the way it handles change detection via scope digests.

Both solutions still require the use and understanding of ES6 promises, especially when dealing with code that only works with callbacks.

You were complaining about having to take non-CS classes, many of which sounded like lower level general education classes, so I offered a potential solution: weed out some of those classes with CLEP exams.

I didn't see that your problem was related to your upper level CS coursework. If you aren't even interested in that, then you really should consider taking a break from school before you burn out. Maybe become a TripleByte candidate or something and get a software engineering job at a startup, or look for a local business that needs someone skilled to help them out.

Read the "Credit By Examination" section on this page:

http://www5.njit.edu/registrar/transfer/

If you're willing to self-study and pay for some tests, you could potentially CLEP out of Physics, Calculus, your non-CS lower-level course requirements, etc. Talk to your registrar.

Testing out of all the basic stuff could cut your list of remaining classes by half, and you won't have to worry about some bad score in a history class bringing down your GPA because you only cared about passing.

And even if you wanted to be well-rounded, it'd still be a good way to bypass boring general education courses and get into more rigorous and interesting upper level classes where the professors and the students care more about the subject matter.

Browsers implement what they call the "same-origin policy" as a cross-site scripting prevention measure. This prevents you from using XMLHttpRequest calls on other hostnames/ports, which effectively means if you're making a static website on a host with no API endpoints, your website can't interact with any backend services. As a result, you can't save or load data from a server-side database or do a lot of other operations that traditional web applications can do.

There's pre-CORS workarounds. You could build an HTML multipart/form-data POST form inside an iframe and submit it with JavaScript for example. And if the server API supports JSONP, you can inject a script tag into your page that loads the target content as a script which then executes the data in a callback to read it back into the client page.

If you don't care about REST, and you only need to do GET/POST requests with a limited set of mime types, you could make a client-side application that gets around the same-origin policy without using CORS. But it's ugly.

With CORS though, you can potentially make any type of request across origins, because the CORS preflight OPTION requests allow a server to specify what request methods and what headers a client from a certain origin can access at a given URI. And these days, you can find CORS-enabled third-party REST APIs that you can use with things like client-side OAuth to provide all the same functionality that you would have in a traditional web applications.

I've been thinking about using a completely split API/client-side app architecture in my own projects lately, because scaling a bare API is much easier and cheaper than scaling a web application.

So yes, CORS is just a security measure, but it gives you more functionality in a client-side application by allowing you to bypass an older security measure, the same-origin policy, in a very clean and explicit way.

The original poster may eventually want to experiment with server side rendering or splitting their single page app into multiple apps, and hash URLs pretty much trap you into a single page app with client side routing.

That said, I didn't mean to cast a negative light on them. Using hash URLs makes it easy to build an app that can be reverse proxied to different hostnames and paths without content rewriting (to change the base tag's url for example), and it works well with legacy browsers.

I would recommend you start by building out a non-trivial project using the tools and technologies you know (jQuery), but try to do a single page application that calls services via RESTful APIs. Bonus points if you can avoid hash urls using the HTML5 History API.

If you're not familiar with the standard Promise API and ES6, add babel and the core-js shim. This gives you things like block scoped variables (let/const), arrow functions, and the new class syntax. Start here. Most new frameworks and tools expect you to know modern JavaScript.

https://babeljs.io/docs/usage/cli/ https://babeljs.io/docs/learn-es2015/ http://exploringjs.com/es6/index.html

Eventually you'll want to start breaking apart your code and organizing it by responsibility/concern. You'll want to use ES6 modules and a tool like WebPack to resolve and bundle your modules all up for production. This also means learning how to configure WebPack to transpile your ES6 code using babel.

http://webpack.github.io/docs/tutorials/getting-started/

Now just focus on building out your project and cleaning it up. Maybe deploy it so real people are using it and you can get some feedback.

Once it's been out there and people are using it, plan a major new feature change or addition. This is where you might start feeling the pain points that are addressed by modern libraries and frameworks. When you do, start researching things like Vue.js, React, Redux, Angular 2, etc. Pick one and migrate/refactor your existing code into it before attempting anything new.

If you follow this approach, then your learning will be needs driven and practical, which keeps it from becoming too academic and uninteresting.