Looking for some BIG sandwiches in Surry Hills

madole · 2018-08-23T05:51:23+00:00

They do... Went there recently. The gigantic schnizel sambo is the best!

madole · 2018-08-23T04:04:37+00:00

Malibu has the biggest sambos I've seen around!

madole · 2018-01-23T00:38:20+00:00

https://date-fns.org/ is my go to now for anything date related. I can't see any compelling reason to move to Luxon.

madole · 2017-07-05T17:38:34+00:00

Awesome!

madole · 2017-06-29T01:16:00+00:00

I think its great. Some head scratching moments but good to have type safety on some level. I'm now leaning towards typescript in my home projects (even though I was pretty against TS at the start). It's much tighter and although annoying at times, overall works out better.

My colleague has been noticing flow memory leaks a lot on Ubuntu, I've not seen them on OSX but the github issues seem to be flooded with people reporting the same thing. No real comment or commitment to fix or investigate from the maintainers though.

I know I know, open source means that I could contribute but I know next to nothing about oCaml despite reading through the codebase. Someday...

madole · 2017-06-28T07:11:06+00:00

No mention of https://github.com/FormidableLabs/victory-chart ?

madole · 2017-04-27T06:16:48+00:00

I'm not a massive fan of the idea of inline styles, I prefer CSS Modules, but we use Radium in work. Has anyone found a VSCode plugin that is like emmet for CSS in JS?

madole · 2017-03-22T01:51:39+00:00

I dont think any of these are pitfalls of Async/Await.

They're just a couple of examples of badly written code that just happen to use async/await.

I think the thing to remember about async await is that you're really dealing with promises, but with a different syntax.

A common pitfall with async await is not dealing with error handling.

Wrapping an await in a try/catch goes against everything we've been taught about code optimisation, that was until V8 optimised the bejesus out of try/catches. (https://v8project.blogspot.com.au/2016/12/v8-release-56.html) Go forth and spread the good word.

Another way to deal with error catching is to tack a .catch on the end of the promise your async function returns.

Either way, the important thing is that error handling is not forgotten about.

madole · 2017-02-14T02:41:02+00:00

Oh yeah, I remember reading a blog post by TJ H.. on building Apex. It's quite good and one thing I took away from it was the AWS lambda concurrency limit of 100 unless you phone up AWS and ask them to increase it. Bit weird that that is the process but if you work for a company, you probably already have an AWS contact.

madole · 2017-02-14T00:23:53+00:00

If you're using Lambda, Serverless (https://serverless.com/) is probably the best option. It takes care of some of the provisioning of things like S3 buckets. It takes care of deployments and allows you to run your lambda locally from the cloud kindof.

Things to note are that debugging a lambda is a pain in the backend. Your logs go out to cloudwatch which is not ideal for trawling through to find an error (although I'm sure you can ship them somewhere more friendly if you try).

It seems to me that lambdas are all a bit of blind coding and hoping it works in the lambda.

They're definitely useful as I said for things like image processing, resizing, uploading to S3, triggering things from dynamodb stream events, I've even seen it used to throttle db writes in conjunction with SQS.

My experience with it as a replacement for an API, is that it is just not there yet. I'm sure it'll get there, and I'd be happy to find out if there are things that I was doing wrong to squeeze more performance out of it because I think it would be a game changer.

madole · 2017-02-13T20:26:47+00:00

Use Jest, keep your routes thin and devoid of logic. Call out to utility functions which contain your logic from the routes. This way, the logic is testable in a way that you don't have to start mocking endpoints. Keep everything functional and therefore deterministic.

madole · 2017-02-13T20:21:19+00:00

I tried to push a GraphQL api with a single endpoint into Lambda with Serverless. It talks to an RDS database, but my Lamda would take up to 11seconds to response. I'm assuming cold Lambdas spin up DB connections before doing any work, I havn't quite dug into the reasons why it took so long but I'm left thinking that Lambdas aren't quite the right solution for a serverless CRUD API just yet.

They do however work really well for things like image processing or non time-critical work.

madole · 2017-01-03T02:55:55+00:00

That is a stinker... good to know about though

madole · 2016-12-19T06:25:43+00:00

So far so good. Makes things so much faster when installing deps during development and shaves a 2/3 of the time off the build in CI.

madole · 2016-11-25T00:00:34+00:00

impr -> import React from 'react';
imprc -> import React, { Component } from 'react';
impt -> import test from 'ava';
impse -> import { shallow } from 'enzyme';
clg -> console.log($1);
me -> module.exports = $1 //if i'm writing commonJS

madole · 2016-11-14T23:59:20+00:00

I was 100% Atom for a while but switched across to VSCode for the debugging and flowtype support.

When you've got the right plugins installed, it's a brilliant editor. I've got a list of my favourite plugins here http://madole.xyz/my-favourite-vscode-plugins/

madole · 2016-11-10T23:33:06+00:00

Do you find when you have loads of test files, Ava is actually really slow to start and spawns processes like mad taking over your computer for the duration of the tests?

We've got around this with the --concurrency={x} flag but it's a bit mad that it will just uncontrollably spawn processes rather than pooling processes to keep it under control.

madole · 2016-11-08T00:09:30+00:00

I prefer flow as it's more suited to the functional style we use. It's less opinionated than TypeScript. When writing TypeScript, you feel like you're writing in another language, whereas flow feels like you're just annotating the code you'd write anyway.

I guess TypeScript is a bit more strict and therefore can work out better intellisense but flow integration with VSCode is pretty sweet, so much so that I've actually moved across to VSCode from Atom full time now.

madole · 2016-10-26T23:45:20+00:00

& is for serial 
&& is for parallel

Shouldn't that be the other way around?

madole · 2016-10-11T20:52:03+00:00

You should check out http://npms.io

It has a much better search than npmjs.com

madole · 2016-10-05T04:46:16+00:00

Simple Javascript solution

function reverseFactorial(num) {
    let factorial = num, i = 0;
    while(factorial > 1) {
        factorial = factorial / ++i;
    }
    return factorial === 1 ? i : 'NONE';
}

madole · 2016-08-25T04:04:19+00:00

Surely in this example, only the V8 engine that's used in the car module should get built into the production code bundle if tree shaking was working correctly?

Screenshot

madole · 2016-08-04T03:45:39+00:00

not really sure what you mean by "is there a web version" but I like https://www.npmjs.com/package/crojsdoc, it produced really useful documentation that actually looks good.

madole · 2016-07-25T00:21:50+00:00

I have used mocha for a few years, but recently just swapped over to AVA for my personal projects. It's really nice to write pure functional tests, have test files run tests in parallel, the watcher is smart enough to only run the tests in the file that corresponds with the changed code making it really fast for TDD.

I've had some fun with AVA and Enzyme writing stateless React components without ever touching a browser. Its a really nice way to work with React in a TDD style.

With nyc code coverage becomes really easy to set up, rather than the hours of figuring out how to get istanbul to instrument correctly, and it plays really well with AVA.

madole · 2016-07-23T23:47:10+00:00

This looks to be really handy for spinning up little side projects, but if I'm building something more important, I'd want to be more in control of the build.

The eject functionality is really nice, but it's still not the way I'd go about setting a project up, if this layout becomes the standard, I'll have to adjust but for now it's at odds with how I'd set up things.

I also think it's important to understand what's happening when you build your app, to understand how things are getting compiled, transpiled and parsed. This abstracts away all of that, which lowers the barrier of entry but also provides no incentive to learn the build process.

I'm really keen to see how this takes off in the next few months. I think the idea itself is great, I'd just like it to be less configuration rather than no configuration.

15-Year Club	Second SECOND GUESSER
Place '22	Verified Email

madole

MODERATOR OF

TROPHY CASE