1,367 karma · joined February 22, 2016
http://nickolinger.com
1. In memory caches for small projects / one-offs.
Redis and memcache are sometimes not needed. Wrapping your cache in an class whose storage is dependency injected is a nice way to keep moving along.
---
2. grep
Not much to say here other than it's a great search tool. Admittedly, I'm still learning working on wielding it even better
---
3. Piping output: [CMD] > myoutput.txt
Lifesaver for large output.
I’d liken the ethos here to: “Move slow and never break things.”
A few queries:
- “PHP use rising”
- “Women in mathematics”
But I was able to break it with something nonsensically narcissistic:
- “Programmers are an elite race”
Great work!
Addressing some of the author's comments, I would agree with:
- Endless ranges
- The "@" syntax names.each { puts @1 }
I would love to see more dialogue on how these changes _could_ positively affect the language. Also, if these are adopted widely, there will be the inevitable Rubocop rule telling you that it prefers this syntax over the "legacy." I love Rubocop, but sometimes I feel there's no end to the journey to writing 'idomatic' ruby and the continued language sprawl definitely does not help on this front.
All of that stuff you hear about in front-end interviews ( like the box-model and relative vs absolute positioning ) comes in handy.
I do admit that pre-flexbox CSS did require some wizardry and hacks here and there. I think "modern CSS" is quite enjoyable and we're able to enjoy a time where we no longer need CSS frameworks to do all the "hard work"
@boleary-gl have you all considered having someone dedicate time each day / week to prioritizing community issues?
General:
- Use a debugger. Stepping through code or existing code is an incredibly quick way to grasp what is going on.
- Exercise healthy paranoia. Expect your code paths to fail. How will you handle failures?
- Code hygiene. Legibility of a codebase makes me respect it a lot more. I feel that I subconsciously handle it with more care when well written.
- Interfaces. Whether your writing an API, a data access utility, etc. -- think about the design in your current and other contexts.
- Language. Whatever language you work in Node, Ruby, Go, etc. know it and its quirks well.
Backend specific:
- Docker. It really changed the way I work. I think the learning curve can be a little steep, but once you're comfortable it leads to much more productive development that is ready for production.
- Load testing. You should be able to identify potential bottlenecks in your application and decide whether they're worth fixing or not.
- Observability. Think about how you will profile and gather metrics of your application when deployed.
- DevOps. A lot of workplaces will expect their SE engineers to help with or even be DevOps. It's a big surface area, so I would focus on knowing the parts of the stack that make your application work (containers, databases, virtual networking)
- Pushing work elsewhere. Sometimes you're going to run into a problem that can't be solved by code changes alone. A basic understanding of how to push workloads elsewhere like message queues / serverless functions and the patterns associated with them. For example, a user uploads an image to your server and you need to compress it.
It was something like:
- Learn ASP, opps we meant ASP.NET web forms. Actually, we meant .NET MVC.
- Oh no, the world wants APIs ... please learn WCF. Actually, we meant .NET Web API.
It seems things have finally calmed down with .NET core. But, along with the MS frameworks you also need to have good command over C# and data access / manipulation utilities such as LINQ, Entity Framework, etc. If you happen to be working with MSSQL Server as I was -- you had to learn it and all of its quirks.
I will say the tooling, once learned, was pretty good everywhere (except WCF in terms of configuration). I can't say that for a lot of front-end utilities, which I think results in a lot of configuration pain and StackOverflow searches.
I do find the answers / guidance on configuring front-end much higher quality than most things in the MS ecosystem, though.
____
My intent here isn't to bash MS so much as it is to point out that the breadth of things you actually have to learn for front-end development is less than some other ecosystems. We're a part of a privileged profession where income and demand is high, so I do expect re-skilling to be an ongoing process.
A person who wants to pay for a bounty would need to submit an issue, and the maintainer estimate it's complexity. At that point, the person filing the issue could click "Buy this issue" if the maintainer has bandwidth.
Again, not easy -- and I'm sure the UX / business / execution would be delicate.
Some ideas that I frequently wish existed:
1. It would be neat if there was some sort of place in Github where people could upvote interesting project ideas, i.e. "Load testing tool in Go"
2. I'd also love to have a way to say, "I can devote 1-5 hours a week to this project" and be notified when someone tags an issue as 'help wanted'
3. Harder, but still do-able (I think). A place for open sourcers to organize a "team" to get a new project off the ground. I often think that there _must_ be other people interested in the same sort of projects I am -- but we have no way to "discover" each other unless you're some high profile Twitter user.
4. Moderation for trolls. Some people frequently open issues that frustrate maintainers. While they can just create a new account, I think creating a small barrier to entry would do some good.
5. A way for companies / individuals / etc. to donate to maintainers through Github. I think this would be a huge incentive for people to continue their work long-term and not just "hand over" repositories to people with ulterior motives.
Though, as you say and I commented below they’re not mutually exclusive. A wrapper or even an entirely separate service can exist alongside others.
One dark side of this is being able to “reach inside” other parts of the monorepo and blur application boundaries.
In some cases, this could be two separate backend projects where you want to re-use the same deployment pipeline.
Often, I find that API wrappers are something that I share across frontends and backends in the JS world, so it often makes sense to separate my projects into:
- backend
- frontend
- common
In Typescript I really like this pattern and can namespace shared types so that it’s very clear to the future reader that this type is probably used outside of the current context.
So, to reply to your comment — I think the term “monorepo” can encompass a lot of different project types.
I think Dan Luu covers the bases quite well here:
Need to change a function signature or interface? Cool, global find & replace.
At some point monorepos outgrow their usefulness. The sheer amount of files in something that’s 10K+ LOC ( not that large, I know ) warrants breaking apart the codebase into packages.
Still, I almost err on the side of monorepos because of the convenience that editors like vscode offer: autocomplete, auto-updating imports, etc.
I've found that I can read and write easier than I can speak, mostly because I have more time to build context in the former. With speaking, synthesizing a thought in a different language (for me) requires use of the language to be a reaction rather than something I think about.
"he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years."
in the thread. Then, I looked through the commits and realized how not ready @right9ctrl was to maintain a heavily used package. Basic linting and small, iterative changes are absent.
So, when I see Dominic-さん just "handing" the package over -- it seems careless. This is often why -- I try to write my own packages unless I absolutely need some sort of framework. It's trading one set of problems for another (the potentiality for bugs vs. a package as a security issue).
Fast forward to living in Tokyo, the difference is night and day (except for the rush hour crowdedness). Maintenance is done every night (somewhere) and all lines shut down between 12 and 1 am. It's super inconvenient, and this is where I applaud NYC for allowing me to get home every late night I spent out. I would hope there's some middle-ground in there, though.
The MTA is looking at this in such a primitive manner, though. I know (from my time there) that track work is not efficient. It looked to be a lot of sit and wait until something is ready. Tokyo metro workers are _always_ doing something. It's almost if they have clear defined goals that they must accomplish before their day starts.
The thing is, I found you have to be very diligent about how you organize your interfaces and how you might namespace them. I had some C# background, and had made a PR or two to the vscode repo -- so I had an idea of "good" code.
I think without some background in how you'll organize you types and, most importantly, types themselves you'll have some legwork in proving Typescript useful.
___
A suggestion I might have, because I found this mentally pleasing: start your project off small (get a few endpoints and some minimal database interaction). Let your co-workers look over it / maybe even do some small amount of work.
Create a typescript branch, where you convert each file to `.ts`. Typescript's compiler `tsc` can copy over all files `.js` and converted `.ts` so it's not essential you do this all at once, but I also found it not-so-painful either.
Demo this branch and show your co-workers that Typescript provides:
- A nice boost in productivity (autocomplete, hurray)
- Some confidence in how you're using types (this isn't a sound type system like flow)
- A way for people who don't have a background in javascript to feel more comfortable
"...with the aim of serving fully consistent data within the next 2 hours."
That's somewhat significant
Looking forward to the write-up. I'm also curious as to how this significant outage lines up with their SLA for enterprise users.
There will be jerks anywhere-- that's a given. But, I can assure you that most of all graduates who come from Berea are very grateful to the institution especially given the insane rate at which tuition continues to increase.
Since it's a liberal arts program, writing and reasoning are a core part of the curriculum. I would say by virtue of going through the program, you're able to better appreciate it at the end. I think learning about the world at an age when your views are malleable is more meaningful than learning about compilers.
I grew up in Appalachia (pronounced "app-uh-lai-cha" by us), and have to say Berea was a godsend. I was lucky to start as desktop support and move on to a network engineer later. The labor program is probably the only reason why I became a somewhat competent programmer out of college, since I was writing "production" code before having my first real full time job. You can read more about the labor program here[1]
The college is very particular about your time there, since it's free and all, so your first year you're not allowed to have a car on campus, enter the opposite sex's dorm rooms, and (in some cases) you're tasked with a job that you may or may not like. Some of this may or may not have changed in the past 10 years. Most people hear this and think, "that's crazy," as I did at the time, but as I've grown older -- I've grown to appreciate it.
Another interesting thing is how forward thinking the community is in the town of Berea. Kentucky isn't the friendliest for being a moderate or liberal, but (I would say) Berea is probably the friendliest community I've ever been apart of. It's a place where you can having engaging discussions and make friends at local establishments (BC&T[2] being my favorite).
With regards to the article, the endowment, and replicating the model -- it would be hard. The college runs itself efficiently while maintaining a high quality of education and student services. Replicating this model elsewhere would mean cutting many staff, removing the luxuries that many people enjoy and most likely lowering salaries. Lower salaries work in Berea because the cost of living is so low; however, that's not the case in many areas and no one is going to volunteer themselves for a salary cut.
The labor program has a lot of infrastructure around it (payroll, staff, processing incoming students) that would be hard to replicate. I think existing universities would have to run a program within or alongside their work-study programs and grow it overtime.
1 - https://www.berea.edu/labor-program-office/a-guide-to-the-la...
2 - https://www.tripadvisor.com/Restaurant_Review-g39187-d222579... ( Seems that they don't have a website )
Things I noticed:
- Brooklyn has undergone an incredible amount of change
- 14th & 6th midtown area maintains a lot of its image
- The amount of change on the west side is uncanny. The Hudson Yards etc.
- Save the Pearl st. area, the financial district still looks like it did
I'm sure there are cases where Promises are still superior, but I think our brains work easier in the x = y sort of notation.
- Show me where you have access to p1 outside of your closure.
The idea is / was -- you need access to both p1 and p2 for some comparison. The first `somePromise` would have been more accurately written `someInitalPromise`
The point is that try/catch + async & await removes a lot of cognitive overhead. Before async/await I rarely used try/catch -- so it's easy to get things done without it, but the combination of the two aforementioned has made codebases I work on much easier to maintain.
If you asked me to identify the most maintainable and easy to read of these two pieces of code, I would say the answer is easy.
Promises:
const p1, p2 = undefined;
somePromise()
.then((res) => {
p1 = somePromise(res);
return anotherPromiseFuncThatNeedsP1(p1);
})
.then((anotherPromiseRes) => {
p2 = anotherPromiseRes;
return p2;
})
.catch(e => {
// log, throw etc.
});
// done
try/catch:
try {
const p1 = await somePromise();
const p2 = await anotherPromiseFuncThatNeedsP1(p1);
// done
} catch(e) {
// log, throw, etc.
}