idea-incubator - [ahy-dee-uh-in-kyuh-bey-ter] - noun
taking ideas, turning them into products and turning them into businesses
Nothing here yet.
Dell Precision 5540 with 8-core i9 at 5GHz, 64GB RAM, 512GB SSD and Quadro graphics running Linux. Currently using its predecessor the Dell Precision 5530 with 6-core i9 at 4.8GHz, 32GB RAM running Kubuntu 19.04 (Fedora was nice too) I'm over Mac, these new Dell Precision laptops are monsters, they're guaranteed to work with Linux and the experience is nicer than MacOS for dev work.
Have one project still using JDK8 which will migrate in January (just one library that needs a version upped), everything else is already JDK11 and working without issues. Using Kotlin, so the Java version doesn't really bring much to the table other than security and performance. I believe Kotlin compiles to JDK8 compatible binaries anyways for the moment, but will be making the jump to 11 soon. JDK 9 and 10 seems to be a lost generation, nobody's using them :-D
Firstly, have a central place for ALL your logs, and by ALL, i mean everything from application logs to database logs to server logs, to access logs, etc so that you can easily correlate if a problem is infrastructure or application related. Previously, i've built my own solutions for this, have used Graylog at some point as well, but these days, it's just very convenient to use Stackdriver, one place for Google Cloud and AWS logs for literally everything. For integrations into third-party systems, log everything, even if it means you need to log it to a separate log system. When something goes wrong, you have a trail of data to figure out if the problem was on your side or the third-party system's side. Your log system should be able to switch from INFO to DEBUG mode at runtime without restarting any services. This allows you to immediately switch to DEBUG mode if anything goes wrong and you'll be able to immediately figure out what is causing the problem. Often times if changing log level requires a restart, that problem would be long gone and take ages to reappear if it's a difficult to reproduce problem. For user-facing systems, it's nice to have the ability to switch a specific user's log level and then tag their logs with their email address or something so that you can follow them in your log system when you filter on a specific tag. This allows you to enable very fine-grained logging, even finer than DEBUG logs (example, user clicked on button class="update account"), so when a user is having issues, you can immediately switch logs on for them and trace exactly what they're doing and what's going wrong. Track browser errors alongside your normal backend logging. Why would you do such a bizarre thing? Often times a browser plugin causes problems on your page which you're not even aware of. It's rather awesome when Steven phones saying he can't print and you're like yes, we're almost done fixing that issue, your browser is using pluginXYZ which is causing the issue, but we're busy deploying a workaround for you. I wrote a mini library for this 4 years ago which does exactly this (it could probably be improved, but it gets the job done for most projects): https://github.com/JVAAS/onerrorjs/blob/master/onerror.js Example index.html page with plenty of things that can cause errors: < html > < head > < title > Test window.onerror </ title > < script type = "text/javascript" src = "onerror.js" > </ script > </ head > < body > < button type = "button" onclick = "substringNullPointer()" > Substring Nullpointer </ button > < button type = "button" onclick = "callInvalidFunction()" > Call Invalid Function </ button > <!-- More Error Testing Buttons Here --> < script type = "text/javascript" > // function that causes null pointer exception function substringNullPointer ( ) { var a = null ; var b = a.substr( 3 ); } // implement submit error jvaas.submitError = function ( error ) { //console.log("Attempting to submit error ..."); //console.info(error); // different error handler urls var javaUrl = "http://localhost:8080/error" ; var phpUrl = "http://localhost/error.php" ; // post error to controller var xhr = new XMLHttpRequest(); xhr.open( 'POST' , javaUrl); xhr.setRequestHeader( 'Content-Type' , 'application/json' ); xhr.onerror = function ( ) { console .info( "Error Failed To Submit, retrying ..." ); console .log(error); jvaas.resubmitError(error); }; xhr.onload = function ( ) { console .info( "Error Submitted" ); console .log(error); }; xhr.send( JSON .stringify(error)); }; </ script > </ body > </ html > onerror.js: // create jvaas namespace var jvaas = jvaas || {}; jvaas.resubmitError = function ( error ) { window .setTimeout( function ( ) { if (jvaas.submitError) { jvaas.submitError(error); } }, 10000 ); } // make sure that window.onerror is supported as precaution we don't want to cause errors when trying to capture errors if ( window .hasOwnProperty( "onerror" )) { window .onerror = function ( a, b, c, d, e, f, g, h ) { // all our code should be in a try-catch to not trigger errors - if we don't, expect an infinite loop try { // uncomment to test the try-catch handler //invalidFunctionThatWillCauseError(); // only add params to array if they are present var data = []; a && data.push(a); b && data.push(b); c && data.push(c); d && data.push(d); e && data.push(e); f && data.push(f); g && data.push(g); h && data.push(h); var error = {}; error[ "date" ] = new Date ().toISOString(); error[ "data" ] = data; error[ "url" ] = window .location.href; error[ "userAgent" ] = navigator.userAgent; // submit error if handler is implemented if (jvaas.submitError) { jvaas.submitError(error); } } catch (error) { // any errors in our try catch should be shown no matter what, even if we have to alert() if ( window .console) { console .error(error); } else { window .alert(error); } } // return false so that we don't swallow the errors return false ; }; } Make sure devs have access to the logs, this way they can fix issues before it becomes a huge problem. At one company, we also implemented error tracking inside Google Analytics (more as a gimmick to see if it was possible), so the marketing department could see if there was a spike in errors after a deploy and raise the alarms. Back in the days, console.log wasn't supported in all browsers and one dev forgot a console.log in his code - within 5 minutes of a production deploy, there was a spike of invalid function console.log next to specific browsers in Google Analytics that didn't support console.log and we sorted the issue out immediately.
I've worked professionally in over a dozen languages, PHP was the worst of the lot. Instead of me writing an enormous post, i can just link to this article which covers the majority of my gripes with the language: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
The amount of chaos depends on the startup's finances, those facing financial troubles are really not a nice place to be whereas those that are well-funded are also chaotic, but in a nice way. So another thing to do before joining an early-stage startup is to do a bit of digging to see what their finances look like. When a startup is having financial troubles and you can afford the gamble (and you've obviously done your homework to see that they're going to get out of that financial trouble), then there's always the option to negotiate for more shares while taking a pay-cut (long-term, this could mean your time investment gets a much bigger pay-out). Joining a startup that is having financial trouble could mean you don't get paid for several months whereas a well-established company has much less risk of this happening.
New MacBook Pros (2016-2019) are terrible, mine (maxed out 2017 version) had a semi-dysfunctional USB-C port, screen was delaminating after 18 months, had overheating issues after 8 months (this was the quad-core version, not even the 6 or 8 core newer models), graphics card glitching so badly some days that i had to use an external monitor, screen sometimes not switching on when opening the lid, random blackouts / freezes and the last straw was the keyboard, some keys getting stuck, another one causing duplicates when you type and my e-key just snapped off, the clips keeping it in place simply broke off. Had the laptop not been stolen after the last repairs, i would probably have thrown it away, every repair meant being without it for a week or more - totally unreliable. (compare this to my 2011 MacBook Pro which lasted for 7 years and which i sold for 50% of the price i bought it for, the news ones just can't handle heavy-duty workloads) Going back to Linux as soon as i can find a replacement machine. Security-wise, in the last 5 years, MacOS was actually doing worse than Windows, security on Linux is still tight compare to the other two. Rossman explains why the new MacBook Pros are bad (i experienced most of these issues): https://www.youtube.com/watch?v=I-0ejhpO1hc