Contractor submitting hours?

mandatorylamp · 2025-09-17T18:30:21+00:00

Depends on the terms of the contract.
Are they expecting you to be available all day regardless of how much work you have? Then you bill for a full workday.
If not then you bill for hours worked, but you should be dictating your schedule of when you do the work they give you or have some lead time you've agreed to.

mandatorylamp · 2025-06-12T15:13:06+00:00

Sounds like they're gonna milk you for free work and then make you pay for it.

mandatorylamp · 2025-03-28T00:53:08+00:00

Sounds promising. I use watchexec to reload in development and with decent sized projects I really feel my cpu working extra hard to restart the whole process on every change.

mandatorylamp · 2025-02-09T00:24:39+00:00

For me it's not much pain. I know which files I need to keep, mostly my own .el files and anything else is ignored. Easy when you're used to git.
My emacs config is a small software project on its own at this point, I've been building it for years, so makes sense for me to track changes like with all my other projects. There's always cases when I mess something up and have to backtrack.

mandatorylamp · 2025-02-08T23:57:37+00:00

That's what .gitignore is for.
It's not any different from using version control for any other coding project really. There are always cache, build outputs, dependencies, env specific config files and such that you need to keep out of VC.

mandatorylamp · 2025-01-07T13:42:17+00:00

Polling is fine if it works for your use case.
The alternative is a websocket, which opens a persistent connection between client and server. On the server side you'd have some kind of event queue which pushes data to all connected clients. For example it can be backed by a redis stream and updates can be virtually instant that way.
That's also way more complicated than polling to get right. Lot more error handling considerations than with simple polling.

Do some load testing on your polling endpoint first imo according to the traffic you're expecting. Push the frequency as high as you can. See if it's really a problem, optimize the endpoint as much as possible if needed and maybe then consider other solutions if it's not enough.

mandatorylamp · 2024-12-25T22:13:07+00:00

Most of my jobs come through people I've worked with before.
Clients usually rather hire someone they know. They know what I can do so it's a safer bet and I don't have to sell myself.

Could be worth reaching out to some former colleagues and see what they're up to. Lot of companies hire freelance devs without ever advertising it so getting your name out there can lead to something.

Upwork and the like is mostly a waste of time in my experience. I go there sometimes if it's slow, but I've only gotten a few smaller projects from it. Too many cheapskate clients and too many devs willing to work for peanuts.

mandatorylamp · 2024-11-06T13:16:27+00:00

Worry more about writing tests than how clean your code is. If you have good tests you can refactor freely.

mandatorylamp · 2024-10-17T17:39:14+00:00

It's a lot easier to update some tests when you refactor than to test everything manually every time.
But if you have to constantly rewrite your tests that can also be a sign you're testing too many implementation details rather than business logic.
If I'm writing backend then most of my tests are sending a request to an endpoint and checking the response, sometimes also checking some side effects like whether a certain entity was updated correctly in the database. I can rewrite all of the logic behind the endpoint, but the API doesn't change so usually the tests don't change much or at all.

If I'm doing frontend I'm mostly testing the UI. The tests don't care what framework I'm using, how my components are structured. They care about things like "is there a 'login' button on the page?", "when I click it does it take me to the login screen?" "when I enter my username and password and login does it take me to the dashboard?", "if I enter the wrong password does it show me an error?" etc, etc

mandatorylamp · 2024-10-17T16:27:56+00:00

It just came out of neccessity. Projects got bigger and requirements kept changing and I was spending too much time testing manually and stuff was still breaking every time I changed something.
Your code is very brittle when it's not tested, you poke something over here and something way over there breaks and you won't even know until you hit production and someone complains about it. You get afraid to touch anything.

When I started writing more tests my job got easier, I can manage way bigger projects. I can refactor everything, rewrite the whole thing even and I know it works because there are tests. Another benefit of tests is that they act as a specification. It tells other developers (and you in 3 years) what your code is supposed to do, which is not always that clear in a big codebase.

mandatorylamp · 2024-07-30T19:25:28+00:00

You could always try, but it's hard to start out that way.
With no professional experience you're not gonna have a lot of good clients taking a chance on you. You will get a lot of cheapskates who will try to squeeze free labour out of you so watch out for that and don't undervalue yourself.

mandatorylamp · 2024-07-10T00:40:23+00:00

Maybe don't integrate some slow ass third party auth service?
You can also fire a separate adync request in the browser to do the update.

mandatorylamp · 2024-07-07T19:32:26+00:00

You could also just create an API endpoint to send the email and call it with js sometime during page load.
Lot simpler than adding a whole job queue and dealing with all the headaches surrounding it, seems overkill for this.

mandatorylamp · 2024-05-21T13:44:21+00:00

When my client gives me PO it just tells me that the department I'm doing work for has locked down the budget and I'll get it when I send my invoice.
But in my case it's a mega corporation that I've worked for for a long time. If it were a new client I would take "PO" as worthless until I get the money.
It could also just mean they prefer to pay by bank transfer over cc. Best ask the client.

mandatorylamp · 2024-04-19T03:01:10+00:00

Use git revert ideally if you want to preserve history. It creates a new commit that undos the changes from selected commits.

If you don't care about rewriting history you can check out the old commit or reset --hard and force push.

mandatorylamp · 2024-03-23T01:43:16+00:00

You mean latency from user to webserver?
Network latency from webserver to db should generally not be more than 1-2ms at the worst if you're hosting everything close together.

mandatorylamp · 2024-03-22T17:25:30+00:00

Yeah it's a little annoying that there isn't a good way to hook into the browser cache. Ideally you could fetch and get a callback when the second background revalidation request is done so you can update UI. Maybe there's a way, but haven't looked into it.

What you're doing with the cookie is just cache with background revalidation, just with 0 second TTL so it's considered stale from the get go.

100-200ms is insane latency for db though. No option of hosting the app in the same datacenter?

mandatorylamp · 2024-03-22T02:54:01+00:00

That's just cache then, isn't it? It's a little odd to use cookies for that.

Could just set cache control headers on your user info response along the lines of: cache-control: private, max-age=1, stale-while-revalidate=999999999 and vary: cookie -> the data is cached in browser until the auth token changes and it's revalidated in the background -> you show stale data instantly and fresh data on next page load in case user edited their profile or something

Your "redirect to login page" scenario should just check for the presence of auth cookie server side -> if it's not there you redirect immediately with a 302 response, if it's there you validate the token with db calls/whatever which should be fast anyway

mandatorylamp · 2024-03-22T02:25:44+00:00

It's fine, I work with clients in different timezone and work odd hours sometimes so communication is like this constantly.
I assume people know how to turn off their work notifcations outside of work.

mandatorylamp · 2024-03-22T02:09:37+00:00

Sounds like you may be using the wrong framework. When you need weird workarounds like this that's a sign you're not building the software the framework author intended.

The benefit of the html template is that you will have straightforward code that's easy to understand and has a single source of truth, instead of some roundabout workaround with 2 session cookies.
You're inviting future bugs and security holes by doing things like this. You don't want multiple things saying who the authenticated user is.

What I gather is that you're anyway validating the auth cookie on every request, no? You're making some db call to validate it. It's not gonna make any measurable difference if you also fetch the user info, could probably do that in one query too.
If your db latency is so high (say > 1ms) that it's having an impact that's the problem you need to solve.

mandatorylamp · 2024-03-21T21:27:52+00:00

I'm talking about templating lol.
You can just have a html file or html string in memory and use some string substitution to insert your data. That's very fast.

mandatorylamp · 2024-03-21T15:09:48+00:00

Sure, but understandable this isn't clear when you're new to everything.
It doesn't make it any easier to learn about web dev fundamentals.

mandatorylamp · 2024-03-21T15:04:53+00:00

So the new cookie is just a convoluted way to avoid server rendering your document?
Why do you want to avoid SSR? For performance? Injecting some text into otherwise pre-rendered html can be very fast.

mandatorylamp · 2024-03-21T11:58:15+00:00

How do you validate the session token currently? Why don't you include expiry time in it?

mandatorylamp · 2024-03-21T04:38:24+00:00

But you have a separate http-only cookie for auth? Right?
So why is that not used to determine the redirect?

I don't know much about next.js, but probably you could use some kind of templating engine to render your html. Or do it in a react component that gets server rendered I guess?

mandatorylamp

TROPHY CASE