jgforbes

Descartes - Finale Inventory | Senior Software Engineer | REMOTE | Full-Time

Finale Inventory is a SaaS application that helps ecommerce sellers manage their operations efficiently. We integrate with over 25 other systems (Amazon, eBay, Shopify, QuickBooks, etc.) to give our customers a complete picture of their business.

We’re a remote-first team that has built a thriving business grounded on long term relationships with our customers and employees.

Our culture is focused on delighting our customers, honesty, transparency, learning and innovating with our colleagues and customers, and constant improvement.

You'll be joining a team of 15 engineers spread across North America, South America, and Western Europe. We use continuous deployment practices to ship code to production several times per day and have a strong test driven development approach. Our technology stack is predominantly JavaScript (Node.js, React) with C++ used in select places for performance.

Interested? Contact Jason Forbes, Director of Software Development, [email protected].

I love 5/3/1 but I don't know if I would recommend it to a beginner. The progression is just too slow compared to one of the daily progression programs like 5x5 or StartingStrength.

Hey all. This post looks at standardizing a time-series for machine learning. The idea is that when you have a running sensor, you have to batch standardize your data to remove any variations in the collection process. A vectorized algorithm for efficiently performing this standardization is presented.

I'm afraid the post got a bit too "math-heavy", but I'll be around the comments to answer any questions.

I would say it depends on what you are trying to learn.

These types of problems will give you a good intro to a language, but won't introduce you to the more advanced libraries which you'll likely need in a professional context (e.g. threading/mutexs, tcp/udp, etc).

Also, and this is a major oversight on my part - I was specifically looking at fitting data generated by an affine function, not “linearly fitting data”. How I titled this is definitely confusing.

Part of what interested me in writing about this though is how the discontinuities changed a trivial problem into something a bit trickier. If the data could be generated by more complex functions, then I would have forgone looking for an easy solution (as an aside, the problem I was working on had sharp timing and hardware constraints which kept me from using a more general solution).

Hey, I’m the author of the post.

You’re completely right. I investigated this as a means for solving the phase-unwrapping problem I was working on, and while it worked relatively well, a more domain specific solution was eventually used.

I purposely stayed away from mentioning phase unwrapping as I was trying to make this as accessible as possible without overloading the reader with jargon. My goal was to more show how problem transformation (like the frequency domain) can sometimes make hard problems far simpler (I was also just playing with data visualization). Looking at it now though, I probably should have added in the conclusion some external resources for people who have the background. It definitely wouldn’t have made the piece less readable, and could have added a bit more value.

I also balked at it, but for the opposite reason. Everyone should be able to sit down to a terminal, make a change to a repository, and commit it.

I mean even if you don't know the command (or they are using a different version control system then you are used to) you can always check the help or man page. It's still a trivial task.

I see a lot of the note apps popping up - what is the fundamental problem that people are trying to solve that hasn't been solved by all the other apps? Is it collaboration or syncing or other?

That's only true if you don't lose capable talent due to the low salaries. If most of the talented French engineers move to Germany to get higher pay, then the low pay will hinder the startup scene.

Personally not a huge fan of two-way binding. As someone who has come from the C#/XAML world (where two-way binding can be abused), I found the pure-functional component strategy for React and similar frameworks to be far, far simpler.

Now, I do agree that it can lead to a bit of boilerplate, but this extra verbosity helps keep a simple mental model for us to reason about. Two-way binding can get very complex when you can have weird cyclical state changes.

1. Hacker News

2. Reddit /r/programming

3. Indiehackers

4. Twitter

5. NYTimes

That is a pretty good walkthrough of the "harder" parts of functional programming.

Although, I always found it telling that the language designers needed the "do" imperative notation for monadic state computations.

While the benefits of monadic-state are pretty well known at this point, it does seem interesting that for widespread adoption it has to be "wrapped" in an abstraction more familiar to developers.

I agree, but feel that this is something that only comes with experience. It's very easy as a new grad to not value your time as much as it's worth (imposter syndrome maybe?).

I signed a contract for $X salary for Y hours of work. If I work 1.5Y I never got paid $1.5X. That's a lesson most developers need to internalize.

I'm a big fan of productivity engineering, but I find this article is a bit light on actual suggestions for increasing the productivity of teams.

I find automating the simple tasks has huge pay-offs as your team grows. Specifically:

* Linting - set up a linter which enforces code quality across the board * Code formatting - similar to linting, but instead of just highlighting errors, automatically fixing them * git pre-commit hooks - Use hooks to run the linter and formatting on pre-commit and reject commits which break company standards * CI - Running test-cases and building on push is the single greatest time saver a company can invest in

I wonder what other things people do.

Funnily enough, GDPR explicitly requires you to have a representative (which for many companies will take the form of a lawyer).

https://gdpr-info.eu/art-27-gdpr/

Hey there are tens of us.

a=1, b=2, c=3, ...

ac = 1 + 3 = 4 bb = 2 + 2 = 4

Bezos addresses this in the letter, mentioning that leaders have to accurately teach the "scope" of the high standards, where scope is a measure of the time required to achieve the set standards.

The CDC [1] considers up to 2 drinks a day for a man to be "moderate" alcohol intake, which would be up to 14 drinks a week.

This doesn't sound like alcoholism to me but that's maybe because of the "moderate" part.

[1] https://www.cdc.gov/alcohol/onlinemedia/infographics/excessi...

If this were true, wouldn't radio have had the same affect?

I've made a similar (albeit far less capable) react framework Dorian.js.

https://github.com/jasongforbes/dorian-js

Takes markdown and yaml to generate a static web-page (designed for landing-pages).

For more information on designing such a framework, see:

https://www.jforbes.io/posts/first-thing-first-part-1

https://www.jforbes.io/posts/first-thing-first-part-2

You might not necessarily want something like code-editors rely on external servers, while still taking advantage of the UX of web-development.

VSCode gets around this by running an npm node locally.

I feel like the "we" in that article is obviously the group of entrepreneurs and not everyone... especially as the subject of the leading sentence is first-time entrepreneurs.

>diamonds' only purpose as jewelry is to show you spent a lot money on them

I wouldn't say that is their only reason. They are also very eye-catching and can be used to accentuate certain features. Their hardness makes their luster and shine outlast other jewelry too.

That isn't to say that diamonds are worth their price, just that the do serve a purpose from a fashion standpoint besides for signaling wealth.

There could be other biases too. For instance, if the Mac users at IBM were in largely technical roles (e.g. working on their MacOS integration service) vs large non-technical departments working on Windows machines (e.g. HR and accounting).

It wouldn't be very surprising that technical departments had less help-desk complaints than non technical departments.

> What, no Newfie jokes?

"How many Newfies does it take to screw in a light-bulb?"

"Don't screw in that light bulb - the power-grid can't take the extra load!"