Init
This commit is contained in:
7
Career/Areas/Design/Design.md
Normal file
7
Career/Areas/Design/Design.md
Normal file
@@ -0,0 +1,7 @@
|
||||
## Books
|
||||
[[Don't make me think]]
|
||||
> When people arrive at a site, they need to know where they are and what to do next, Like entering a large store.
|
||||
>
|
||||
> This is made hard by the fact people don't read. To deal with this, elements need to be in the expected places, labels need to be short and clear (not clever).
|
||||
>
|
||||
> Some people click, others search. Make sure there is a search bar.
|
||||
6
Career/Areas/Interviews.md
Normal file
6
Career/Areas/Interviews.md
Normal file
@@ -0,0 +1,6 @@
|
||||
- Tell me something about one of your projects.
|
||||
- What when well?
|
||||
- What went well that you did not expect to go well?
|
||||
- What went wrong?
|
||||
- -_OWhat went wrong even though you did not expect it to give you any trouble
|
||||
What question do you want me to ask
|
||||
12
Career/Areas/Project management/Boss class.md
Normal file
12
Career/Areas/Project management/Boss class.md
Normal file
@@ -0,0 +1,12 @@
|
||||
Episode one
|
||||
Before every agenda point mark it if it's about input, decision or awareness. Also make clear the stakeholders and ownership.
|
||||
Creating structure where others can hook into so they can pace themself. It's not only about being charismatic, it's about creating a process.
|
||||
|
||||
**[Agenda Point: Awareness] Stakeholders & Ownership**
|
||||
Creating structure where others can engage is crucial. This isn't just about possessing charisma; it's about establishing a process that facilitates involvement.
|
||||
|
||||
**[Agenda Point: Input] Involvement of Team Members**
|
||||
Ensure that every team member has the opportunity to provide input. This fosters a collaborative environment and enhances decision-making.
|
||||
|
||||
**[Agenda Point: Decision] Implementation of Decisions**
|
||||
Decisions should be made with clear understanding of their impact on all stakeholders. This approach ensures that decisions are made thoughtfully and inclusively.
|
||||
3
Career/Areas/Project management/Next, maybe.md
Normal file
3
Career/Areas/Project management/Next, maybe.md
Normal file
@@ -0,0 +1,3 @@
|
||||
|
||||
Recomandations on managing people
|
||||
<https://news.ycombinator.com/item?id=39336840>
|
||||
44
Career/Articles/Brag document.md
Normal file
44
Career/Articles/Brag document.md
Normal file
@@ -0,0 +1,44 @@
|
||||
|
||||
Hi, I am the lead developer at Strixi. I want you to help me build a brag document. A list of all the accomplishments that week, so these can discussed at a later date. For more info see these links:
|
||||
<https://www.thefountaininstitute.com/blog/brag-documents>
|
||||
<https://jvns.ca/blog/brag-documents/>
|
||||
|
||||
Hi, I am the lead developer at Strixi. I want you to help me build a brag document. A list of all the accomplishments that week, so these can discussed at a later date.
|
||||
Now I want you to help build this document by start asking questions about what I did last week and why. As I answer, start building this document. No need to ask about specicic ticked numbers, just ask about projects.
|
||||
|
||||
## Strixi Weekly Brag: June 20–27, 2025
|
||||
|
||||
### 1. Features & Deliverables Shipped
|
||||
|
||||
- **Invoicing Module Overhaul**
|
||||
|
||||
- **QLS Data Export**
|
||||
• Built a CSV/JSON export so invoicing totals can be reconciled against the customer’s system.
|
||||
|
||||
- **Checklist for Air Waybills**
|
||||
• Created a step-by-step checklist UI for warehouse staff to verify receipt of AWBs before invoicing.
|
||||
|
||||
- **Initial Data Exchange Setup**
|
||||
|
||||
- Configured a data pipeline between QLS handling and a third-party customs-declaration service to automate customs data flow.
|
||||
|
||||
### 2. Technical Improvements & Bug Fixes
|
||||
|
||||
- **AI-Assisted JS→TS Migration**
|
||||
• Leveraged OpenAI Codex to translate JavaScript modules into TypeScript.
|
||||
• Identified and patched a styling bug within an hour—demonstrated rapid feedback cycles and improved code robustness.
|
||||
|
||||
### 3. Collaboration & Leadership
|
||||
|
||||
- **Solo Development & Stakeholder Communication**
|
||||
• Operated as the sole developer on the invoicing initiative—self-directed requirement gathering, design, and delivery.
|
||||
• Led all communications with the third-party customs-declaration partner: organized kickoff discussions, negotiated API specs, and coordinated integration timelines.
|
||||
|
||||
### 4. Metrics & Impact
|
||||
|
||||
- Features deployed June 27, 2025; usage data pending. (Reminder set for July 4, 2025 to follow up.)
|
||||
|
||||
### 5. Professional Development
|
||||
|
||||
- **OpenAI Codex Experimentation**
|
||||
• Assessed productivity gains from AI-driven code modernization; uncovered a bug and improved overall TypeScript coverage.
|
||||
137
Career/Articles/Drunk engineer.md
Normal file
137
Career/Articles/Drunk engineer.md
Normal file
@@ -0,0 +1,137 @@
|
||||
<https://www.reddit.com/r/ExperiencedDevs/s/ThNlcBi373>
|
||||
|
||||
I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.
|
||||
|
||||
- The best way I've advanced my career is by changing companies.
|
||||
|
||||
- Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.
|
||||
|
||||
- There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.
|
||||
|
||||
- I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.
|
||||
|
||||
- I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.
|
||||
|
||||
- If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.
|
||||
|
||||
- pour another glass
|
||||
|
||||
- Qualities of a good manager share a lot of qualities of a good engineer.
|
||||
|
||||
- When I first started, I was enamored with technology and programming and computer science. I'm over it.
|
||||
|
||||
- Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.
|
||||
|
||||
- The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
|
||||
|
||||
- Related to above, writing good proposals for changes is a great skill.
|
||||
|
||||
- Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.
|
||||
|
||||
- The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.
|
||||
|
||||
- If I ever find myself thinking I'm the smartest person in the room, it's time to leave.
|
||||
|
||||
- I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.
|
||||
|
||||
- We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.
|
||||
|
||||
- _sip_
|
||||
|
||||
- Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.
|
||||
|
||||
- Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.
|
||||
|
||||
- The greatest programming language ever is lisp. I should learn lisp.
|
||||
|
||||
- For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.
|
||||
|
||||
- Tests are important but TDD is a damn cult.
|
||||
|
||||
- Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.
|
||||
|
||||
- Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.
|
||||
|
||||
- Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then _maybe_ they are worth something within this decade.
|
||||
|
||||
- Work from home is the tits. But lack of whiteboarding sucks.
|
||||
|
||||
- I've never worked at FAANG so I don't know what I'm missing. But I've hired (and not hired) engineers from FAANGs and they don't know what they're doing either.
|
||||
|
||||
- My self worth is not a function of or correlated with my total compensation. Capitalism is a poor way to determine self-worth.
|
||||
|
||||
- Managers have less power than you think. Way less power. If you ever thing, why doesn't Manager XYZ fire somebody, it's because they can't.
|
||||
|
||||
- Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.
|
||||
|
||||
- Speaking of titles: early in your career, title changes up are nice. Junior to Mid. Mid to Senior. Senior to Lead. Later in your career, title changes _down_ are nice. That way, you can get the same compensation but then get an increase when you're promoted. In other words, early in your career (<10 years), title changes UP are good because it lets you grow your skills and responsibilities. Later, title changes down are nice because it lets you grow your salary.
|
||||
|
||||
- Max out our 401ks.
|
||||
|
||||
- Be kind to everyone. Not because it'll help your career (it will), but because being kind is rewarding by itself.
|
||||
|
||||
- If I didn't learn something from the junior engineer or intern this past month, I wasn't paying attention.
|
||||
|
||||
- Oops I'm out of wine.
|
||||
|
||||
- Paying for classes, books, conferences is worth it. I've done a few conferences, a few 1.5k courses, many books, and a subscription. Worth it. This way, I can better pretend what I'm doing.
|
||||
|
||||
- Seriously, why aren't webdevs paid more? They know everything!!!
|
||||
|
||||
- Carpal tunnel and back problems are no joke. Spend the 1k now on good equipment.
|
||||
|
||||
- The smartest man I've every worked for was a Math PhD. I've learned so much from that guy. I hope he's doing well.
|
||||
|
||||
- Once, in high school, there was thing girl who was a great friend of mine. I mean we talked and hung out and shared a lot of personal stuff over a few years. Then there was a rumor that I liked her or that we were going out or whatever. She didn't take that too well so she started to ignore me. That didn't feel too good. I guess this would be the modern equivalent to "ghosting". I don't wish her any ill will though, and I hope she's doing great. I'm sorry I didn't handle that better.
|
||||
|
||||
- I had a girlfriend in 8th grade that I didn't want to break up with even though I didn't like her anymore so I just started to ignore her. That was so fucked up. I'm sorry, Lena.
|
||||
|
||||
- You know what the best part of being a software engineer is? You can meet and talk to people who think like you. Not necessarily the same interests like sports and TV shows and stuff. But they think about problems the same way you think of them. That's pretty cool.
|
||||
|
||||
- There's not enough women in technology. What a fucked up industry. That needs to change. I've been trying to be more encouraging and helpful to the women engineers in our org, but I don't know what else to do.
|
||||
|
||||
- Same with black engineers. What the hell?
|
||||
|
||||
- I've never really started hating a language or technology until I started becoming intimately familiar with it. Also, I think a piece of tech is good if I hate it but I simultaneously would recommend it to a client. Fuck Jenkins but man I don't think I would be commuting software malpractice by recommending it to a new client.
|
||||
|
||||
- That being said, git is awful and I have choice but to use it. Also, GUI git tools can go to hell, give me the command line any day. There's like 7 command lines to memorize, everything else can be googled.
|
||||
|
||||
- Since I work in data, I'm going to give a data-specific lessons learned. Fuck pandas.
|
||||
|
||||
- My job is easier because I have semi-technical analysts on my team. Semi-technical because they know programming but not software engineering. This is a blessing because if something doesn't make sense to them, it means that it was probably badly designed. I love the analysts on the team; they've helped me grow so much more than the most brilliant engineers.
|
||||
|
||||
- Dark mode is great until you're forced to use light mode (webpage or an unsupported app). That's why I use light mode.
|
||||
|
||||
- I know enough about security to know that I don't know shit about security.
|
||||
|
||||
- Crap I'm out of wine.
|
||||
|
||||
- Being a good engineer means knowing best practices. Being a senior engineer means knowing when to break best practices.
|
||||
|
||||
- If people are trying to assign blame to a bug or outage, it's time to move on.
|
||||
|
||||
- A lot of progressive companies, especially startups, talk about bringing your "authentic self". Well what if your authentic self is all about watching porn? Yeah, it's healthy to keep a barrier between your work and personal life.
|
||||
|
||||
- I love drinking with my co-workers during happy hour. I'd rather spend time with kids, family, or friends.
|
||||
|
||||
- The best demonstration of great leadership is when my leader took the fall for a mistake that was 100% my fault. You better believe I would've walked over fire for her.
|
||||
|
||||
- On the same token, the best leaders I've been privileged to work under did their best to both advocate for my opinions and also explain to me other opinions 'that conflict with mine. I'm working hard to be like them.
|
||||
|
||||
- Fuck side projects. If you love doing them, great! Even if I had the time to do side-projects, I'm too damn busy writing drunken posts on reddit
|
||||
|
||||
- Algorithms and data strictures are important--to a point. I don't see pharmacist interviews test trivia about organic chemistry. There's something fucked with our industry's interview process.
|
||||
|
||||
- Damn, those devops guys and gals are f'ing smart. At least those mofos get paid though.
|
||||
|
||||
- It's not important to do what I like. It's more important to do what I don't hate.
|
||||
|
||||
- The closer I am to the product, the closer I am to driving revnue, the more I feel valued regardless of how technical my work is. This has been true for even the most progressive companies.
|
||||
|
||||
- Linux is important even when I was working in all Windows. Why? Because I eventually worked in Linux. So happy for those weekend where I screwed around installing Arch.
|
||||
|
||||
- I've learned to be wary for ambiguous buzz words like big data. WTF is "big" data? I've dealt with 10k rows streaming every 10 minutes in Spark and Kafka and dealt with 1B rows batched up hourly in Python and MySQL. Those labels can go fuck themselves.
|
||||
|
||||
- Not all great jobs are in Silicon Valley. But a lot are.
|
||||
|
||||
Finally, if you really want to hurt me, don't downvote I don't care about that. Just ignore this post. Nothing makes me sadder than when I wrote a long post and then nobody responds. So if you hate this post, just ignore.
|
||||
@@ -0,0 +1,200 @@
|
||||
[[ReadItLater]] [[Article]]
|
||||
|
||||
# [Get your work recognized: write a brag document](https://jvns.ca/blog/brag-documents/)
|
||||
|
||||
There’s this idea that, if you do great work at your job, people will (or should!) automatically recognize that work and reward you for it with promotions / increased pay. In practice, it’s often more complicated than that – some kinds of important work are more visible/memorable than others. It’s frustrating to have done something really important and later realize that you didn’t get rewarded for it just because the people making the decision didn’t understand or remember what you did. So I want to talk about a tactic that I and lots of people I work with have used!
|
||||
|
||||
This blog post isn’t just about being promoted or getting raises though. The ideas here have actually been more useful to me to help me reflect on themes in my work, what’s important to me, what I’m learning, and what I’d like to be doing differently. But they’ve definitely helped with promotions!
|
||||
|
||||
You can also [skip to the brag document template at the end](https://jvns.ca/blog/brag-documents/#template).
|
||||
|
||||
### you don’t remember everything you did
|
||||
|
||||
One thing I’m always struck by when it comes to performance review time is a feeling of “wait, what *did* I do in the last 6 months?“. This is a kind of demoralizing feeling and it’s usually not based in reality, more in “I forgot what cool stuff I actually did”.
|
||||
|
||||
I invariably end up having to spend a bunch of time looking through my pull requests, tickets, launch emails, design documents, and more. I always end up finding small (and sometimes not-so-small) things that I completely forgot I did, like:
|
||||
|
||||
- mentored an intern 5 months ago
|
||||
- did a small-but-important security project
|
||||
- spent a few weeks helping get an important migration over the line
|
||||
- helped X put together this design doc
|
||||
- etcetera!
|
||||
|
||||
### your manager doesn’t remember everything you did
|
||||
|
||||
And if you don’t remember everything important you did, your manager (no matter how great they are!) probably doesn’t either. And they need to explain to other people why you should be promoted or given an evaluation like “exceeds expectations” (“X’s work is so awesome!!!!” doesn’t fly).
|
||||
|
||||
So if your manager is going to effectively advocate for you, they need help.
|
||||
|
||||
### here’s the tactic: write a document listing your accomplishments
|
||||
|
||||
The tactic is pretty simple! Instead of trying to remember everything you did with your brain, maintain a “brag document” that lists everything so you can refer to it when you get to performance review season! This is a pretty common tactic – when I started doing this I mentioned it to more experienced people and they were like “oh yeah, I’ve been doing that for a long time, it really helps”.
|
||||
|
||||
Where I work we call this a “brag document” but I’ve heard other names for the same concept like “hype document” or “list of stuff I did” :).
|
||||
|
||||
There’s a basic template for a brag document at the end of this post.
|
||||
|
||||
When I first wrote a brag document I was kind of nervous about sharing it with my manager. It felt weird to be like “hey, uh, look at all the awesome stuff I did this year, I wrote a long document listing everything”. But my manager was really thankful for it – I think his perspective was “this makes my job way easier, now I can look at the document when writing your perf review instead of trying to remember what happened”.
|
||||
|
||||
Giving them a document that explains your accomplishments will really help your manager advocate for you in discussions about your performance and come to any meetings they need to have prepared.
|
||||
|
||||
Brag documents also **really** help with manager transitions – if you get a new manager 3 months before an important performance review that you want to do well on, giving them a brag document outlining your most important work & its impact will help them understand what you’ve been doing even though they may not have been aware of any of your work before.
|
||||
|
||||
Similarly, if your company does peer feedback as part of the promotion/perf process – share your brag document with your peer reviewers!! Every time someone shares their doc with me I find it SO HELPFUL with writing their review for much the same reasons it’s helpful to share it with your manager – it reminds me of all the amazing things they did, and when they list their goals in their brag document it also helps me see what areas they might be most interested in feedback on.
|
||||
|
||||
On some teams at work it’s a team norm to share a brag document with peer reviewers to make it easier for them.
|
||||
|
||||
### explain the big picture
|
||||
|
||||
In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?
|
||||
|
||||
In my brag document, I like to do this by making a section for areas that I’ve been focused on (like “security”) and listing all the work I’ve done in that area there. This is especially good if you’re working on something fuzzy like “building a stronger culture of code review” where all the individual actions you do towards that might be relatively small and there isn’t a big shiny ship.
|
||||
|
||||
### use your brag document to notice patterns
|
||||
|
||||
In the past I’ve found the brag document useful not just to hype my accomplishments, but also to reflect on the work I’ve done. Some questions it’s helped me with:
|
||||
|
||||
- What work do I feel most proud of?
|
||||
- Are there themes in these projects I should be thinking about? What’s the big picture of what I’m working on? (am I working a lot on security? localization?).
|
||||
- What do I wish I was doing more / less of?
|
||||
- Which of my projects had the effect I wanted, and which didn’t? Why might that have been?
|
||||
- What could have gone better with project X? What might I want to do differently next time?
|
||||
|
||||
### you can write it all at once or update it every 2 weeks
|
||||
|
||||
Many people have told me that it works best for them if they take a few minutes to update their brag document every 2 weeks ago. For me it actually works better to do a single marathon session every 6 months or every year where I look through everything I did and reflect on it all at once. Try out different approaches and see what works for you!
|
||||
|
||||
### don’t forget to include the fuzzy work
|
||||
|
||||
A lot of us work on fuzzy projects that can feel hard to quantify, like:
|
||||
|
||||
- improving code quality on the team / making code reviews a little more in depth
|
||||
- making on call easier
|
||||
- building a more fair interview process / performance review system
|
||||
- refactoring / driving down technical debt
|
||||
|
||||
A lot of people will leave this kind of work out because they don’t know how to explain why it’s important. But I think this kind of work is especially important to put into your brag document because it’s the most likely to fall under the radar! One way to approach this is to, for each goal:
|
||||
|
||||
1. explain your goal for the work (why do you think it’s important to refactor X piece of code?)
|
||||
2. list some things you’ve done towards that goal
|
||||
3. list any effects you’ve seen of the work, even if they’re a little indirect
|
||||
|
||||
If you tell your coworkers this kind of work is important to you and tell them what you’ve been doing, maybe they can also give you ideas about how to do it more effectively or make the effects of that work more obvious!
|
||||
|
||||
### encourage each other to celebrate accomplishments
|
||||
|
||||
One nice side effect of having a shared idea that it’s normal/good to maintain a brag document at work is that I sometimes see people encouraging each other to record & celebrate their accomplishments (“hey, you should put that in your brag doc, that was really good!”). It can be hard to see the value of your work sometimes, especially when you’re working on something hard, and an outside perspective from a friend or colleague can really help you see why what you’re doing is important.
|
||||
|
||||
Brag documents are good when you use them on your own to advocate for yourself, but I think they’re better as a collaborative effort to recognize where people are excelling.
|
||||
|
||||
Next, I want to talk about a couple of structures that we’ve used to help people recognize their accomplishments.
|
||||
|
||||
### the brag workshop: help people list their accomplishments
|
||||
|
||||
The way this “brag document” practice started in the first place is that my coworker [Karla](https://karla.io/) and I wanted to help other women in engineering advocate for themselves more in the performance review process. The idea is that some people undersell their accomplishments more than they should, so we wanted to encourage those people to “brag” a little bit and write down what they did that was important.
|
||||
|
||||
We did this by running a “brag workshop” just before performance review season. The format of the workshop is like this:
|
||||
|
||||
**Part 1: write the document: 1-2 hours**. Everybody sits down with their laptop, starts looking through their pull requests, tickets they resolved, design docs, etc, and puts together a list of important things they did in the last 6 months.
|
||||
|
||||
**Part 2: pair up and make the impact of your work clearer: 1 hour**. The goal of this part is to pair up, review each other’s documents, and identify places where people haven’t bragged “enough” – maybe they worked on an extremely critical project to the company but didn’t highlight how important it was, maybe they improved test performance but didn’t say that they made the tests 3 times faster and that it improved everyone’s developer experience. It’s easy to accidentally write “I shipped $feature” and miss the follow up (“… which caused $thing to happen”). Another person reading through your document can help you catch the places where you need to clarify the impact.
|
||||
|
||||
### biweekly brag document writing session
|
||||
|
||||
Another approach to helping people remember their accomplishments: my friend Dave gets some friends together every couple of weeks or so for everyone to update their brag documents. It’s a nice way for people to talk about work that they’re happy about & celebrate it a little bit, and updating your brag document as you go can be easier than trying to remember everything you did all at once at the end of the year.
|
||||
|
||||
These don’t have to be people in the same company or even in the same city – that group meets over video chat and has people from many different companies doing this together from Portland, Toronto, New York, and Montreal.
|
||||
|
||||
In general, especially if you’re someone who really cares about your work, I think it’s really positive to share your goals & accomplishments (and the things that haven’t gone so well too!) with your friends and coworkers. It makes it feel less like you’re working alone and more like everyone is supporting each other in helping them accomplish what they want.
|
||||
|
||||
### thanks
|
||||
|
||||
Thanks to Karla Burnett who I worked with on spreading this idea at work, to Dave Vasilevsky for running brag doc writing sessions, to Will Larson who encouraged me to start one [of these](https://lethain.com/career-narratives/) in the first place, to my manager Jay Shirley for always being encouraging & showing me that this is a useful way to work with a manager, and to Allie, Dan, Laura, Julian, Kamal, Stanley, and Vaibhav for reading a draft of this.
|
||||
|
||||
I’d also recommend the blog post [Hype Yourself! You’re Worth It!](http://blog.aashni.me/2019/01/hype-yourself-youre-worth-it/) by Aashni Shah which talks about a similar approach.
|
||||
|
||||
## Appendix: brag document template
|
||||
|
||||
Here’s a template for a brag document! Usually I make one brag document per year. (“Julia’s 2017 brag document”). I think it’s okay to make it quite long / comprehensive – 5-10 pages or more for a year of work doesn’t seem like too much to me, especially if you’re including some graphs/charts / screenshots to show the effects of what you did.
|
||||
|
||||
One thing I want to emphasize, for people who don’t like to brag, is – **you don’t have to try to make your work sound better than it is**. Just make it sound **exactly as good as it is**! For example “was the primary contributor to X new feature that’s now used by 60% of our customers and has gotten Y positive feedback”.
|
||||
|
||||
### Goals for this year:
|
||||
|
||||
- List your major goals here! Sharing your goals with your manager & coworkers is really nice because it helps them see how they can support you in accomplishing those goals!
|
||||
|
||||
### Goals for next year
|
||||
|
||||
- If it’s getting towards the end of the year, maybe start writing down what you think your goals for next year might be.
|
||||
|
||||
### Projects
|
||||
|
||||
For each one, go through:
|
||||
|
||||
- What your contributions were (did you come up with the design? Which components did you build? Was there some useful insight like “wait, we can cut scope and do what we want by doing way less work” that you came up with?)
|
||||
- The impact of the project – who was it for? Are there numbers you can attach to it? (saved X dollars? shipped new feature that has helped sell Y big deals? Improved performance by X%? Used by X internal users every day?). Did it support some important non-numeric company goal (required to pass an audit? helped retain an important user?)
|
||||
|
||||
Remember: don’t forget to explain what the results of you work actually were! It’s often important to go back a few months later and fill in what actually happened after you launched the project.
|
||||
|
||||
### Collaboration & mentorship
|
||||
|
||||
Examples of things in this category:
|
||||
|
||||
- Helping others in an area you’re an expert in (like “other engineers regularly ask me for one-off help solving weird bugs in their CSS” or “quoting from the C standard at just the right moment”)
|
||||
- Mentoring interns / helping new team members get started
|
||||
- Writing really clear emails/meeting notes
|
||||
- Foundational code that other people built on top of
|
||||
- Improving monitoring / dashboards / on call
|
||||
- Any code review that you spent a particularly long time on / that you think was especially important
|
||||
- Important questions you answered (“helped Risha from OTHER\_TEAM with a lot of questions related to Y”)
|
||||
- Mentoring someone on a project (“gave Ben advice from time to time on leading his first big project”)
|
||||
- Giving an internal talk or workshop
|
||||
|
||||
### Design & documentation
|
||||
|
||||
List design docs & documentation that you worked on
|
||||
|
||||
- Design docs: I usually just say “wrote design for X” or “reviewed design for X”
|
||||
- Documentation: maybe briefly explain the goal behind this documentation (for example “we were getting a lot of questions about X, so I documented it and now we can answer the questions more quickly”)
|
||||
|
||||
### Company building
|
||||
|
||||
This is a category we have at work – it basically means “things you did to help the company overall, not just your project / team”. Some things that go in here:
|
||||
|
||||
- Going above & beyond with interviewing or recruiting (doing campus recruiting, etc)
|
||||
- Improving important processes, like the interview process or writing better onboarding materials
|
||||
|
||||
### What you learned
|
||||
|
||||
My friend Julian suggested this section and I think it’s a great idea – try listing important things you learned or skills you’ve acquired recently! Some examples of skills you might be learning or improving:
|
||||
|
||||
- how to do performance analysis & make code run faster
|
||||
- internals of an important piece of software (like the JVM or Postgres or Linux)
|
||||
- how to use a library (like React)
|
||||
- how to use an important tool (like the command line or Firefox dev tools)
|
||||
- about a specific area of programming (like localization or timezones)
|
||||
- an area like product management / UX design
|
||||
- how to write a clear design doc
|
||||
- a new programming language
|
||||
|
||||
It’s really easy to lose track of what skills you’re learning, and usually when I reflect on this I realize I learned a lot more than I thought and also notice things that I’m *not* learning that I wish I was.
|
||||
|
||||
### Outside of work
|
||||
|
||||
It’s also often useful to track accomplishments outside of work, like:
|
||||
|
||||
- blog posts
|
||||
- talks/panels
|
||||
- open source work
|
||||
- Industry recognition
|
||||
|
||||
I think this can be a nice way to highlight how you’re thinking about your career outside of strictly what you’re doing at work.
|
||||
|
||||
This can also include other non-career-related things you’re proud of, if that feels good to you! Some people like to keep a combined personal + work brag document.
|
||||
|
||||
### General prompts
|
||||
|
||||
If you’re feeling stuck for things to mention, try:
|
||||
|
||||
- If you were trying to convince a friend to come join your company/team, what would you tell them about your work?
|
||||
- Did anybody tell you that you did something well recently?
|
||||
Binary file not shown.
16
Career/Articles/Really good shadows.md
Normal file
16
Career/Articles/Really good shadows.md
Normal file
@@ -0,0 +1,16 @@
|
||||
<https://www.reddit.com/r/webdev/s/sNN2DpeOzC>
|
||||

|
||||
' Yes, it can be done. Here are my tips with turning CSS shadows into something that looks more tangible.
|
||||
|
||||
1. It takes about 3 drop-shadow attributes to make one good-looking, realistic shadow. One very close and very opaque, with very little blur, to represent the ambient occlusion within the shadow, a second one to represent the base shadow (more transparent, more blur, farther from the item), and a third shadow with very high blur, very far distance, and very low opacity to represent the ambient occlusion outside of the shadow.
|
||||
2. Shadows should be colored according to what light would do in the scenario. So, for example, a shadow should take on the color of the surface it is on, and the color of the surface it would be reflecting light from.
|
||||
3. Inset shadows are necessary to convey depth on the surface. You must use light colors, again factoring point #2 in mind, and some minimal darker colors as well, and offset them to give depth. Typically you need at least two inset shadows to achieve a good depth: one short-range opaque shadow to replicate the tangible edge of the surface, and one longer-range transparent shadow to represent the general fall-off and light reflection on the broader surface.
|
||||
4. Very soft gradients can help convey depth, but should not be overtly noticeable. For example, a foreground can be slightly lighter at the top, and slightly darker on the bottom, and if done subtly enough, the user won't even notice it is happening, but it will convey better, more tangible depth to the item. Notice how the backgrounds on both image do this to convey a light source.
|
||||
|
||||
Of course all shadows (inset and out) should be angled appropriately to a common light source, and the general distance should be determined by how "thick" you want the foreground to look. Generally, thicker items are harder to convincingly convey than thinner ones.
|
||||
|
||||
This takes a lot of work, and I recommend doing all designing in a vector graphics tool like Affinity Designer or Adobe Illustrator before moving into CSS. Excessive shadows can have a negative impact on performance on some older devices, although I rarely see this occur.
|
||||
|
||||
Here is a rough and quick codepin demonstrating these tactics: <https://codepen.io/atalkingfish/pen/YzBLgQB>
|
||||
|
||||
PLEASE NOTE: Just because you can do this doesn't mean it will look good, fit the application, be trendy, etc. Currently, websites with a lot of depth don't usually look very trendy and current.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
created: 2023-10-24 18:47
|
||||
updated: 2025-06-28 14:54
|
||||
---
|
||||
- Companies don't really care about a salary increase
|
||||
- Never tell them a number focus on seeing if your are a match
|
||||
- Don't start negotiating until there is a yes if situation
|
||||
- Use their own words those are convincing to them
|
||||
- Confirm any promises in an email asking if you understood correctly
|
||||
- Talk about their problems, that is what they care about
|
||||
- If you need to stall pretend you need to talk it over with the family
|
||||
- If they tell you something is out of there control, sympathise and switch to something they can control
|
||||
|
||||
[[Salary Negotiation - Make More Money, Be More Valued.pdf]]
|
||||
|
||||
#salary
|
||||
|
||||
When you are providing revised text,
|
||||
- ask if the user wants to make any changes to the tone
|
||||
- ask if the user use specific words.
|
||||
- ask if the user wants to see multiple versions of the revised text.
|
||||
- ask if the user wants to see the corrections
|
||||
- ask if the user suggestions to improve the text.
|
||||
Binary file not shown.
11
Career/Articles/Salary.md
Normal file
11
Career/Articles/Salary.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
created: 2025-07-03 12:09
|
||||
updated: 2025-07-03 12:27
|
||||
---
|
||||
Ziggo Abbo 55,00
|
||||
Odido Abbo 55.50
|
||||
Salaery 4737.53
|
||||
|
||||
2025-07-03
|
||||
About an hour overhead, 15min travel, 45 min forced lunch
|
||||
~7600 all incl ~44 euro an hour
|
||||
Binary file not shown.
12
Career/Brag Document.md
Normal file
12
Career/Brag Document.md
Normal file
@@ -0,0 +1,12 @@
|
||||
## Goals for This Year:
|
||||
|
||||
- Build a proper event based architecture system
|
||||
## Goals for next Year
|
||||
## Projects
|
||||
- What your contributions were (did you come up with the design? Which components did you build? Was there some useful insight like “wait, we can cut scope and do what we want by doing way less work” that you came up with?)
|
||||
- The impact of the project – who was it for? Are there numbers you can attach to it? (saved X dollars? shipped new feature that has helped sell Y big deals? Improved performance by X%? Used by X internal users every day?). Did it support some important non-numeric company goal (required to pass an audit? helped retain an important user?)
|
||||
### QLS Handling
|
||||
- Roll out of new bug tracker, allowing users to provide bug reports, lowering the load on first line support
|
||||
|
||||
## 2025 W5
|
||||
Send to customers work floor to comunicate directly with users and extract requiredments and nice to haves.
|
||||
65
Career/BragDocument/BragDocument.md
Normal file
65
Career/BragDocument/BragDocument.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
created: 2025-10-10 16:13
|
||||
updated: 2025-10-10 16:43
|
||||
---
|
||||
# Brag Document
|
||||
|
||||
A record of professional accomplishments, projects, and growth.
|
||||
|
||||
## 2025
|
||||
|
||||
### October
|
||||
|
||||
#### Week of October 7-13, 2025
|
||||
|
||||
**Projects & Initiatives**
|
||||
- **Transport Company Self-Planning Feature (QLS Handling)** - Implemented capability for trusted transport companies to independently plan shipments and assign trips to themselves, removing dependency on QLS planners. Feature now deployed and actively used by first transport company.
|
||||
- **DECO Customs Declaration Integration (QLS Handling)** - Deep dive into Dutch customs authority documentation for DECO process (simplified import customs for declarations under €150 for e-commerce). Preparing to implement customs declaration capability for the QLS Handling project.
|
||||
- **Codebase Maintenance** - Ongoing work using AI tools to improve housekeeping, simplify test setups, and remove inconsistencies across the codebase.
|
||||
|
||||
**Technical Achievements**
|
||||
- **Authorization & Scoping Architecture** - Modified authorization system and global database scopes to support dual assignment methods: traditional assignment by QLS planners and new self-assignment by transport companies planning their own freight.
|
||||
- **Complex Documentation Analysis** - Navigated ecosystem of ~20 interconnected Dutch customs documents with cross-references to UN standard data exchange lists and various code lists. Created DTOs and Enums with extensive comments to make information searchable within the editor when AI tools (Claude, ChatGPT) struggled with document cross-referencing.
|
||||
- **Minimal UI Impact Design** - Leveraged existing planner UI components for transport company self-planning feature, requiring minimal new UI development.
|
||||
|
||||
**Impact & Results**
|
||||
- **Reduced Operational Load** - Transport self-planning feature directly reduces workload for QLS planning team.
|
||||
- **Improved Transporter Efficiency** - Transport companies can now optimize truck utilization by finding and assigning their own shipments.
|
||||
- **Feature Adoption** - First transport company already using the self-planning capability in production.
|
||||
- **Foundation for Customs Compliance** - DECO documentation work establishes foundation for customs declaration capability, critical for e-commerce shipments entering the Netherlands.
|
||||
|
||||
**Skills Developed**
|
||||
- **Customs & Regulatory Domain Knowledge** - Deep understanding of Dutch customs DECO process, message exchange protocols, and the complex regulatory ecosystem of interconnected standards and code lists.
|
||||
- **Document Architecture Pattern** - Developed strategy for managing complex, cross-referenced regulatory documentation by consolidating into searchable code artifacts when traditional AI tools fail at cross-referencing.
|
||||
|
||||
**Collaboration & Leadership**
|
||||
- Independent project execution with access to consultants as needed (no blockers requiring escalation yet).
|
||||
|
||||
**Recognition**
|
||||
- New feature requests received based on transport self-planning capability.
|
||||
|
||||
---
|
||||
|
||||
## Template for Future Entries
|
||||
|
||||
### [Month]
|
||||
|
||||
#### Week of [Date Range]
|
||||
|
||||
**Projects & Initiatives**
|
||||
- [What you worked on]
|
||||
|
||||
**Technical Achievements**
|
||||
- [Technical problems solved, technologies learned, improvements made]
|
||||
|
||||
**Impact & Results**
|
||||
- [Quantifiable outcomes, metrics, business impact]
|
||||
|
||||
**Skills Developed**
|
||||
- [New skills, tools, or knowledge gained]
|
||||
|
||||
**Collaboration & Leadership**
|
||||
- [Mentoring, helping others, leading initiatives]
|
||||
|
||||
**Recognition**
|
||||
- [Praise, awards, positive feedback received]
|
||||
65
Career/BragDocument/CLAUDE.md
Normal file
65
Career/BragDocument/CLAUDE.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||
|
||||
## Repository Purpose
|
||||
|
||||
This is a personal career documentation repository for maintaining a "brag document" - a weekly/monthly record of professional accomplishments, projects, technical achievements, and career growth.
|
||||
|
||||
## File Structure
|
||||
|
||||
- `BragDocument.md` - Main document tracking career achievements organized chronologically (year → month → week)
|
||||
|
||||
## Workflow: Weekly Brag Document Update
|
||||
|
||||
When the user requests a brag document update, follow this interview process:
|
||||
|
||||
### 1. Initial Questions
|
||||
- What projects or initiatives have you been working on this week?
|
||||
- For each project mentioned, ask follow-up questions:
|
||||
- What is the purpose/context of this project?
|
||||
- What technical work did you do?
|
||||
- Were there any challenges or interesting problems you solved?
|
||||
- What's the current status? (complete, deployed, in progress)
|
||||
|
||||
### 2. Impact & Results Questions
|
||||
- What was the impact or benefit of this work?
|
||||
- Any quantifiable outcomes? (metrics, workload reduction, efficiency gains)
|
||||
- Is it being used? By whom?
|
||||
|
||||
### 3. Skills & Learning Questions
|
||||
- Any new skills, tools, or technologies learned or deepened?
|
||||
- Any domain knowledge gained?
|
||||
|
||||
### 4. Collaboration Questions
|
||||
- Are you working solo or with a team?
|
||||
- Any mentoring, helping others, or leadership activities?
|
||||
|
||||
### 5. Recognition Questions
|
||||
- Any positive feedback, recognition, or praise received?
|
||||
- Feature requests or follow-up work generated by your accomplishments?
|
||||
|
||||
### 6. Other Work
|
||||
- Any other notable work? (bug fixes, code reviews, meetings, housekeeping, refactoring)
|
||||
- Roughly how much time spent on each area of work?
|
||||
|
||||
### 7. Document Update
|
||||
Once you have enough information, update `BragDocument.md` under the current week's section with these categories:
|
||||
|
||||
**Projects & Initiatives** - High-level summary of what was worked on
|
||||
**Technical Achievements** - Specific technical problems solved, architecture decisions, implementation details
|
||||
**Impact & Results** - Business value, operational improvements, user benefits
|
||||
**Skills Developed** - New knowledge or deepened expertise
|
||||
**Collaboration & Leadership** - Team work, helping others, independent execution
|
||||
**Recognition** - Feedback, praise, or follow-up requests
|
||||
|
||||
### Writing Style
|
||||
- Use bold for project/feature names
|
||||
- Include context (what/why) along with accomplishments
|
||||
- Focus on impact and outcomes, not just activities
|
||||
- Be specific about technologies, systems, and domains
|
||||
- Frame accomplishments positively and professionally
|
||||
- Quantify when possible (number of documents, days spent, users affected)
|
||||
|
||||
### Adding New Time Periods
|
||||
When starting a new week/month, add a new dated section at the top of the current month, or create a new month section if needed. Keep the template at the bottom of the document for reference.
|
||||
9
Career/C.V..md
Normal file
9
Career/C.V..md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
created: 2025-07-10 14:49
|
||||
updated: 2025-07-10 14:52
|
||||
---
|
||||
|
||||
vue js pinia
|
||||
AWS services, RDS, Aurora, VPN, EC2, S3
|
||||
Responsible for pipeline, Force, Envoyer, Bitbucket
|
||||
And ofcourse git, although I have no idea how it works I made custom bash functions for just about everything.
|
||||
10
Career/Career.md
Normal file
10
Career/Career.md
Normal file
@@ -0,0 +1,10 @@
|
||||
---
|
||||
sorting-spec: |-
|
||||
Projects
|
||||
Area
|
||||
%
|
||||
Resources
|
||||
Archive
|
||||
created: 2025-07-04 07:38
|
||||
updated: 2025-07-04 07:40
|
||||
---
|
||||
37
Career/Interview questions.md
Normal file
37
Career/Interview questions.md
Normal file
@@ -0,0 +1,37 @@
|
||||
|
||||
https://programming.dev/post/567025
|
||||
|
||||
- How long does it take for code to be deployed after being committed?
|
||||
- How often do team members move teams?
|
||||
- What kinds of (soft or hard) skills do you need most on the team right now?
|
||||
- Do you have a defined onboarding process?
|
||||
-
|
||||
- Does the team maintain deployment infrastructure? Production infrastructure? Is there an on-call rotation?
|
||||
- What does your planning cycle look like? Scrum? Kanban? Meetings?
|
||||
- What’s one thing you would change or improve on the team if you could snap your fingers?
|
||||
- What would you like to be doing less and more of on your team?
|
||||
- How does the product representative interact with the eng team?
|
||||
- Do you have a career ladder, with levels, and expectations at each of the level defined?
|
||||
- What is your performance review cycle like? 1:1s?
|
||||
- what is your policy for overtime or comp time when there are evening or weekend emergencies?
|
||||
-
|
||||
|
||||
### Devops
|
||||
|
||||
|
||||
### Currently working on
|
||||
- What has your team been working on recently? What new changes have you shipped in the last six months?
|
||||
- What is the biggest difficulty your team is facing right now?
|
||||
- How long has the team existed and how long have you been managing it?
|
||||
|
||||
### Current working procedures
|
||||
- What is the remote work policy? And is there is any possibility that, this policy will change?
|
||||
- Is the team all remote? Are you?
|
||||
- How often do tasks and priorities change last minute?
|
||||
- How flexible are they on work hours?
|
||||
|
||||
### Expectation
|
||||
- How long does it take for people to get up to speed as new hires?
|
||||
- How much would a new hire be doing in six months?
|
||||
- How often do people tend to need to be available outside of standard working hours?
|
||||
- What does success in this position look like for me 6 months down the road?
|
||||
6
Career/Laravel Queues.md
Normal file
6
Career/Laravel Queues.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
created: 2025-07-09 08:56
|
||||
updated: 2025-07-09 08:58
|
||||
---
|
||||
By default a job does not throw an exception when timed out.
|
||||
There is a retry_after parameter in the queue config that should be greater then the timeout in the queue worker otherwise other workers will start to retry already / still running jobs.
|
||||
9
Career/Others/AWS Cheatsheet.md
Normal file
9
Career/Others/AWS Cheatsheet.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
created: 2025-01-09 13:45
|
||||
updated: 2025-07-04 07:19
|
||||
---
|
||||
### Export a hosted zone from Route53
|
||||
```bash
|
||||
aws route53 list-resource-record-sets --hosted-zone-id {{zone-id}} --output json > zone.json
|
||||
```
|
||||
#Snippets #AWS
|
||||
7
Career/Others/Apache.md
Normal file
7
Career/Others/Apache.md
Normal file
@@ -0,0 +1,7 @@
|
||||
## Block Bots / User Agents
|
||||
```
|
||||
RewriteEngine On
|
||||
RewriteCond %{HTTP_USER_AGENT} (Amazonbot|SemrushBot|meta-externalagent|Bytespider) [NC]
|
||||
RewriteRule .* - [R=503,L]
|
||||
|
||||
```
|
||||
51
Career/Others/Audit Dependencies Command.md
Normal file
51
Career/Others/Audit Dependencies Command.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
created: 2025-07-03 10:20
|
||||
updated: 2025-07-04 07:26
|
||||
tags:
|
||||
- Laravel
|
||||
- Snippets
|
||||
---
|
||||
|
||||
```bash
|
||||
php artisan make:command AuditDependenciesCommand
|
||||
```
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
namespace App\Console\Commands;
|
||||
|
||||
use Exception;
|
||||
use Illuminate\Console\Command;
|
||||
use Illuminate\Support\Facades\Process;
|
||||
use Spatie\FlareClient\Enums\MessageLevels;
|
||||
use Spatie\LaravelIgnition\Facades\Flare;
|
||||
|
||||
class AuditDependenciesCommand extends Command
|
||||
{
|
||||
protected $signature = 'app:audit-dependencies';
|
||||
|
||||
public function handle(): void
|
||||
{
|
||||
$composer = Process::run('composer audit');
|
||||
|
||||
if (!blank($composer->output())) {
|
||||
$this->warn('Composer audit found vulnerabilities');
|
||||
Flare::glow('Composer audit found vulnerabilities', MessageLevels::WARNING, ['output' => $composer->output()]);
|
||||
Flare::report(new Exception('Composer audit found vulnerabilities'));
|
||||
}
|
||||
|
||||
$npm = Process::run('npm audit');
|
||||
|
||||
if (trim($npm->output()) !== "found 0 vulnerabilities") {
|
||||
$this->warn('NPM audit found vulnerabilities');
|
||||
Flare::glow('NPM audit found vulnerabilities', MessageLevels::WARNING, ['output' => $npm->output()]);
|
||||
Flare::report(new Exception('NPM audit found vulnerabilities'));
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```php in kernel
|
||||
$schedule->command(\App\Console\Commands\AuditDependenciesCommand::class)->daily();
|
||||
```
|
||||
47
Career/Others/Audit Dependencies/Audit Dependencies.md
Normal file
47
Career/Others/Audit Dependencies/Audit Dependencies.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
created: 2025-07-09 10:20
|
||||
updated: 2025-07-09 10:20
|
||||
---
|
||||
```bash
|
||||
php artisan make:command AuditDependenciesCommand
|
||||
```
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
namespace App\Console\Commands;
|
||||
|
||||
use Exception;
|
||||
use Illuminate\Console\Command;
|
||||
use Illuminate\Support\Facades\Log;
|
||||
use Illuminate\Support\Facades\Process;
|
||||
use Spatie\LaravelIgnition\Facades\Flare;
|
||||
|
||||
class AuditDependenciesCommand extends Command
|
||||
{
|
||||
protected $signature = 'app:audit-dependencies';
|
||||
|
||||
public function handle(): void
|
||||
{
|
||||
$composer = Process::run('composer audit');
|
||||
|
||||
if (!blank($composer->output())) {
|
||||
$this->warn('Composer audit found vulnerabilities');
|
||||
Log::warning('Composer audit found vulnerabilities', ['output' => $composer->output()]);
|
||||
Flare::report(new Exception('Composer audit found vulnerabilities'));
|
||||
}
|
||||
|
||||
$npm = Process::run('npm audit');
|
||||
|
||||
if (trim($npm->output()) !== "found 0 vulnerabilities") {
|
||||
$this->warn('NPM audit found vulnerabilities');
|
||||
Log::warning('NPM audit found vulnerabilities', ['output' => $npm->output()]);
|
||||
Flare::report(new Exception('NPM audit found vulnerabilities'));
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```php kernel
|
||||
$schedule->command(\App\Console\Commands\AuditDependenciesCommand::class)->daily();
|
||||
```
|
||||
36
Career/Others/Css Stricksa.md
Normal file
36
Career/Others/Css Stricksa.md
Normal file
@@ -0,0 +1,36 @@
|
||||
|
||||
|
||||
h-[1lh]
|
||||
|
||||
Tap size target add absolute span in button next to the svg / icon
|
||||
``` html
|
||||
<span class="absolute top-1/2 left-1/2 -translate-1/2 size-12 [@media(pointer:fine)]:hidden"></span>
|
||||
```
|
||||
|
||||
scrollable table
|
||||
|
||||
``` html
|
||||
<div class="-mx-parent flex margin-whatever overflow-x-auto">
|
||||
<div class="px-parent grow">
|
||||
<table class="min-w-full whitescape-nowrap">
|
||||
// Bla
|
||||
<table/>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
Easier if there is a css variable of page padding
|
||||
|
||||
Grid stuff
|
||||
|
||||
```html
|
||||
|
||||
<div class="grid grid-cols-[auto_1fr]">
|
||||
<a class="col-span-2 grid grid-cols-subgrid">
|
||||
<icon class="mr-2" />
|
||||
<label />
|
||||
</a>
|
||||
</div>
|
||||
|
||||
```
|
||||
|
||||
#css #frontend
|
||||
39
Career/Others/Css Tricks.md
Normal file
39
Career/Others/Css Tricks.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
created: 2025-07-03 09:50
|
||||
updated: 2025-07-04 07:19
|
||||
---
|
||||
|
||||
|
||||
h-[1lh]
|
||||
|
||||
Tap size target add absolute span in button next to the svg / icon
|
||||
``` html
|
||||
<span class="absolute top-1/2 left-1/2 -translate-1/2 size-12 [@media(pointer:fine)]:hidden"></span>
|
||||
```
|
||||
|
||||
scrollable table
|
||||
|
||||
``` html
|
||||
<div class="-mx-parent flex margin-whatever overflow-x-auto">
|
||||
<div class="px-parent grow">
|
||||
<table class="min-w-full whitescape-nowrap">
|
||||
// Bla
|
||||
<table/>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
Easier if there is a css variable of page padding
|
||||
|
||||
Grid stuff
|
||||
|
||||
```html
|
||||
|
||||
<div class="grid grid-cols-[auto_1fr]">
|
||||
<a class="col-span-2 grid grid-cols-subgrid">
|
||||
<icon class="mr-2" />
|
||||
<label />
|
||||
</a>
|
||||
</div>
|
||||
|
||||
```
|
||||
#Snippets #CSS
|
||||
51
Career/Others/Deployment Hooks.md
Normal file
51
Career/Others/Deployment Hooks.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
created: 2025-02-24 13:13
|
||||
updated: 2025-07-04 07:20
|
||||
---
|
||||
|
||||
|
||||
### Clone New Release
|
||||
### Install Composer Dependencies
|
||||
|
||||
### NPM
|
||||
|
||||
```bash
|
||||
cd {{ release }}
|
||||
|
||||
echo {{ sha }} >> commit_hash.txt
|
||||
|
||||
php artisan ziggy:generate
|
||||
# php artisan translation:generate-vue
|
||||
|
||||
nice -n 19 npm ci
|
||||
nice -n 19 npm run build
|
||||
```
|
||||
|
||||
|
||||
### Activate New Release
|
||||
|
||||
### Artisan
|
||||
``` bash
|
||||
cd {{ release }}
|
||||
|
||||
php artisan optimize:clear
|
||||
php artisan horizon:terminate
|
||||
|
||||
php artisan migrate --force
|
||||
|
||||
php artisan optimize
|
||||
php artisan filament:optimize
|
||||
|
||||
# php artisan generate:sitemap
|
||||
# php artisan l5-swagger:generate
|
||||
```
|
||||
|
||||
### Purge Old Releases
|
||||
|
||||
### Run Deployment Operations
|
||||
```bash
|
||||
cd {{ release }}
|
||||
|
||||
php artisan operations
|
||||
```
|
||||
#Laravel #Deployments
|
||||
10
Career/Others/Deployment Operations.md
Normal file
10
Career/Others/Deployment Operations.md
Normal file
@@ -0,0 +1,10 @@
|
||||
---
|
||||
created: 2025-02-24 09:57
|
||||
updated: 2025-07-04 07:24
|
||||
tags:
|
||||
- Laravel/Packages
|
||||
---
|
||||
```bash
|
||||
composer require dragon-code/laravel-deploy-operations && php artisan vendor:publish --tag=config --provider="DragonCode\LaravelDeployOperations\ServiceProvider"
|
||||
```
|
||||
#Laravel/Packages
|
||||
153
Career/Others/Eslint.md
Normal file
153
Career/Others/Eslint.md
Normal file
@@ -0,0 +1,153 @@
|
||||
---
|
||||
created: 2025-02-24 09:46
|
||||
updated: 2025-07-04 07:24
|
||||
tags:
|
||||
- BuildTools
|
||||
---
|
||||
|
||||
```bash
|
||||
npm uninstall @typescript-eslint/eslint-plugin eslint-plugin-unused-imports eslint-plugin-vue eslint eslint-plugin-tailwindcss eslint-plugin-vue eslint-plugin-no-relative-import-paths eslint-config-prettier prettier prettier-plugin-organize-imports prettier-plugin-tailwindcss typescript-eslint @vue/eslint-config-typescript @eslint/js
|
||||
```
|
||||
|
||||
|
||||
```bash
|
||||
npm install -D eslint @typescript-eslint/eslint-plugin eslint-plugin-no-relative-import-paths eslint-plugin-unused-imports eslint-plugin-tailwindcss eslint-plugin-vue globals @eslint/js @eslint/eslintrc @vue/eslint-config-typescript @eslint/js
|
||||
|
||||
```
|
||||
|
||||
```bash
|
||||
npx @eslint/migrate-config .eslintrc.json
|
||||
```
|
||||
|
||||
```js eslint.config.js
|
||||
import vue from "eslint-plugin-vue";
|
||||
import unusedImports from "eslint-plugin-unused-imports";
|
||||
import noRelativeImportPaths from 'eslint-plugin-no-relative-import-paths';
|
||||
import {defineConfigWithVueTs, vueTsConfigs} from '@vue/eslint-config-typescript';
|
||||
import tailwind from "eslint-plugin-tailwindcss";
|
||||
|
||||
export default defineConfigWithVueTs(
|
||||
vue.configs['flat/recommended'],
|
||||
tailwind.configs["flat/recommended"],
|
||||
vueTsConfigs.recommended,
|
||||
{
|
||||
ignores: ['vendor', 'node_modules', 'public', 'bootstrap/ssr', 'tailwind.config.js', 'resources/js/components/ui/*'],
|
||||
},
|
||||
{
|
||||
rules: {
|
||||
'vue/html-indent': ['error', 4, {
|
||||
attribute: 1,
|
||||
baseIndent: 1,
|
||||
closeBracket: 0,
|
||||
alignAttributesVertically: true,
|
||||
ignores: [],
|
||||
}],
|
||||
'vue/block-lang': 'off',
|
||||
'vue/multi-word-component-names': 'off',
|
||||
'@typescript-eslint/no-explicit-any': 'off',
|
||||
"linebreak-style": ["error", "unix"],
|
||||
"tailwindcss/no-custom-classname": "off",
|
||||
"vue/no-mutating-props": "off",
|
||||
"vue/prop-name-casing": "off",
|
||||
"vue/no-setup-props-destructure": "off",
|
||||
"vue/require-default-prop": "off"
|
||||
},
|
||||
},
|
||||
{
|
||||
plugins: {
|
||||
"unused-imports": unusedImports,
|
||||
},
|
||||
},
|
||||
{
|
||||
plugins: {
|
||||
'no-relative-import-paths': noRelativeImportPaths,
|
||||
},
|
||||
rules: {
|
||||
"no-relative-import-paths/no-relative-import-paths": [
|
||||
"warn",
|
||||
{
|
||||
"allowSameFolder": false,
|
||||
"rootDir": "resources/js",
|
||||
"prefix": "@"
|
||||
}
|
||||
],
|
||||
|
||||
},
|
||||
},
|
||||
{
|
||||
settings: {
|
||||
tailwindcss: {
|
||||
config: './tailwind.config.js',
|
||||
callees: ["classnames", "clsx", "ctl", 'twMerge'],
|
||||
},
|
||||
},
|
||||
rules: {
|
||||
"tailwindcss/no-custom-classname": "off",
|
||||
}
|
||||
},
|
||||
);
|
||||
```
|
||||
|
||||
```js .eslintrc.json
|
||||
{
|
||||
"env": {
|
||||
"browser": true,
|
||||
"es2021": true,
|
||||
"node": true
|
||||
},
|
||||
"extends": [
|
||||
"eslint:recommended",
|
||||
"plugin:vue/vue3-recommended",
|
||||
"plugin:@typescript-eslint/recommended",
|
||||
"plugin:tailwindcss/recommended"
|
||||
],
|
||||
"overrides": [],
|
||||
"parser": "vue-eslint-parser",
|
||||
"parserOptions": {
|
||||
"parser": "@typescript-eslint/parser",
|
||||
"ecmaVersion": "latest",
|
||||
"sourceType": "module"
|
||||
},
|
||||
"plugins": [
|
||||
"vue",
|
||||
"@typescript-eslint",
|
||||
"unused-imports",
|
||||
"no-relative-import-paths"
|
||||
],
|
||||
"rules": {
|
||||
"linebreak-style": [
|
||||
"error",
|
||||
"unix"
|
||||
],
|
||||
"vue/multi-word-component-names": "off",
|
||||
"tailwindcss/no-custom-classname": "off",
|
||||
"vue/html-indent": [
|
||||
"error",
|
||||
4,
|
||||
{
|
||||
"attribute": 1,
|
||||
"baseIndent": 1,
|
||||
"closeBracket": 0,
|
||||
"alignAttributesVertically": true,
|
||||
"ignores": []
|
||||
}
|
||||
],
|
||||
"vue/require-default-prop": "off",
|
||||
"vue/no-mutating-props": "off",
|
||||
"no-relative-import-paths/no-relative-import-paths": [
|
||||
"warn",
|
||||
{
|
||||
"allowSameFolder": false,
|
||||
"rootDir": "resources/js",
|
||||
"prefix": "@"
|
||||
}
|
||||
],
|
||||
"vue/prop-name-casing": "off",
|
||||
"vue/no-setup-props-destructure": "off"
|
||||
},
|
||||
"ignorePatterns": [
|
||||
"**/vue-i18n-locales.generated.js",
|
||||
"**/ziggy.js"
|
||||
]
|
||||
}
|
||||
```
|
||||
108
Career/Others/Flare/Flare.md
Normal file
108
Career/Others/Flare/Flare.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
created: 2025-02-12 12:01
|
||||
updated: 2025-07-04 07:27
|
||||
tags:
|
||||
- Laravel/Packages
|
||||
---
|
||||
# Install / update
|
||||
```bash
|
||||
npm uninstall @flareapp/flare-client @flareapp/flare-vue @flareapp/js @flareapp/vite @flareapp/vite-plugin-sourcemap-uploader @flareapp/vue
|
||||
```
|
||||
|
||||
```bash
|
||||
npm install @flareapp/js @flareapp/vue @flareapp/vite
|
||||
```
|
||||
|
||||
```bash
|
||||
composer require spatie/laravel-activitylog spatie/laravel-ignition
|
||||
```
|
||||
|
||||
```js flare.js
|
||||
import {flare} from "@flareapp/js";
|
||||
|
||||
flare.beforeSubmit = (report) => {
|
||||
|
||||
// Filter out errors that are not useful
|
||||
if ([
|
||||
'Request failed with status code 401',
|
||||
'Network Error',
|
||||
'Failed to fetch dynamically imported module',
|
||||
'is not a valid JavaScript MIME type',
|
||||
'Unable to preload CSS',
|
||||
'Request aborted',
|
||||
'Importing a module script failed.',
|
||||
].some(v => report.message.includes(v))) {
|
||||
return false;
|
||||
}
|
||||
|
||||
// Filter silly bots
|
||||
if ([
|
||||
'adsbot',
|
||||
'googlebot'
|
||||
].some(v => report.context.request.useragent.includes(v))) {
|
||||
return false;
|
||||
}
|
||||
|
||||
return report;
|
||||
};
|
||||
|
||||
export default flare;
|
||||
```
|
||||
|
||||
```js app.js
|
||||
import {flareVue} from "@flareapp/vue";
|
||||
import flare from './plugins/flare';
|
||||
|
||||
if (import.meta.env.PROD) {
|
||||
flare.light();
|
||||
}
|
||||
|
||||
// createApp()
|
||||
.use(flareVue)
|
||||
//. .mount(el)
|
||||
```
|
||||
|
||||
```js vite.config.js
|
||||
import flareSourcemapUploader from '@flareapp/vite';
|
||||
return {
|
||||
plugins: [
|
||||
// bla
|
||||
flareSourcemapUploader({
|
||||
key: env.VITE_FLARE_KEY,
|
||||
}),
|
||||
],
|
||||
};
|
||||
```
|
||||
|
||||
```php AppServiceProvider
|
||||
private function versionStuff(): void
|
||||
{
|
||||
\Illuminate\Support\Facades\App::macro('getVersion', function () {
|
||||
if (app()->isLocal()) {
|
||||
return time();
|
||||
}
|
||||
|
||||
if (file_exists(base_path('commit_hash.txt'))) {
|
||||
return trim(file_get_contents(base_path('commit_hash.txt')));
|
||||
}
|
||||
|
||||
return md5(base_path());
|
||||
});
|
||||
|
||||
\Illuminate\Support\Facades\Cache::macro('getVersion', function () {
|
||||
return app()->isLocal() ? time() : \Illuminate\Support\Facades\Cache::remember('version', now()->addDay(), fn() => App::getVersion());
|
||||
});
|
||||
|
||||
\Spatie\LaravelIgnition\Facades\Flare::determineVersionUsing(function () {
|
||||
return \Illuminate\Support\Facades\Cache::getVersion();
|
||||
});
|
||||
}
|
||||
|
||||
private function startLogBatch(): void
|
||||
{
|
||||
if (!\Spatie\Activitylog\Facades\LogBatch::isOpen()) {
|
||||
\Spatie\Activitylog\Facades\LogBatch::startBatch();
|
||||
\Illuminate\Support\Facades\Context::add('batch_uuid', \Spatie\Activitylog\Facades\LogBatch::getUuid());
|
||||
}
|
||||
}
|
||||
```
|
||||
8
Career/Others/Formkit/Formkit.md
Normal file
8
Career/Others/Formkit/Formkit.md
Normal file
@@ -0,0 +1,8 @@
|
||||
---
|
||||
created: 2025-07-09 10:20
|
||||
updated: 2025-07-09 10:20
|
||||
---
|
||||
|
||||
``` bash
|
||||
npm install @formkit/vue
|
||||
```
|
||||
92
Career/Others/Horizon.md
Normal file
92
Career/Others/Horizon.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
created: 2025-03-13 14:23
|
||||
updated: 2025-07-04 07:23
|
||||
tags:
|
||||
- Laravel/Packages
|
||||
---
|
||||
|
||||
``` bash
|
||||
php artisan make:command CheckStatusCommand && php artisan make:notification HorizonIsInactiveNotification
|
||||
```
|
||||
|
||||
``` php CheckStatusCommand
|
||||
<?php
|
||||
|
||||
namespace App\Console\Commands;
|
||||
|
||||
use App\Notifications\HorizonIsInactiveNotification;
|
||||
use Illuminate\Console\Command;
|
||||
use Illuminate\Support\Facades\Notification;
|
||||
use Laravel\Horizon\Contracts\MasterSupervisorRepository;
|
||||
|
||||
class CheckStatusCommand extends Command
|
||||
{
|
||||
protected $description = 'Command description';
|
||||
protected $signature = 'horizon:check-status';
|
||||
|
||||
/**
|
||||
* Execute the console command.
|
||||
*/
|
||||
public function handle(): void
|
||||
{
|
||||
if (!$this->shouldBeActive()) {
|
||||
return;
|
||||
}
|
||||
|
||||
if ($this->isHorizonActive()) {
|
||||
return;
|
||||
}
|
||||
|
||||
$this->error('Horizon is inactive on: ' . config('app.name'));
|
||||
|
||||
Flare::report(new Exception('Horizon is inactive'));
|
||||
|
||||
Notification::route('mail', 'dev@strixi.nl')
|
||||
->notify(new HorizonIsInactiveNotification());
|
||||
}
|
||||
|
||||
protected function isHorizonActive(): bool
|
||||
{
|
||||
if (!$masters = app(MasterSupervisorRepository::class)->all()) {
|
||||
return false;
|
||||
}
|
||||
|
||||
return collect($masters)->some(fn($master): bool => $master->status !== 'paused');
|
||||
}
|
||||
|
||||
protected function shouldBeActive(): bool
|
||||
{
|
||||
return config('queue.default') === 'redis';
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
``` php HorizonIsInactiveNotification
|
||||
<?php
|
||||
|
||||
namespace App\Notifications;
|
||||
|
||||
use Illuminate\Notifications\Messages\MailMessage;
|
||||
use Illuminate\Notifications\Notification;
|
||||
|
||||
class HorizonIsInactiveNotification extends Notification
|
||||
{
|
||||
public function via(object $notifiable): array
|
||||
{
|
||||
return ['mail'];
|
||||
}
|
||||
|
||||
public function toMail(object $notifiable): MailMessage
|
||||
{
|
||||
return (new MailMessage)
|
||||
->subject('Horizon is inactive on: ' . config('app.name'))
|
||||
->line('Horizon is inactive on: ' . config('app.name'))
|
||||
->action('Goto site', url(config('app.url')));
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
``` php kernel or bootstrap
|
||||
$schedule->command(\App\Console\Commands\CheckStatusCommand::class)->everyFifteenMinutes();
|
||||
```
|
||||
11
Career/Others/Laravel relationships.md
Normal file
11
Career/Others/Laravel relationships.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
created: 2025-02-06 11:23
|
||||
updated: 2025-07-04 07:36
|
||||
---
|
||||
### belongsToMany
|
||||
|
||||
Argument query
|
||||
belongsToMany($related, $table = null, $foreignPivotKey = null, $relatedPivotKey = null, $parentKey = null, $relatedKey = null, $relation = null)
|
||||
```mysql
|
||||
select `related_table`.*, `table`.`foreignPivotKey` as `pivot_foreignPivotKey`, `table`.`relatedPivotKey` as `pivot_relatedPivotKey` from `networks` inner join `table` on `networks`.`relatedKey` = `table`.`relatedPivotKey` where `table`.`foreignPivotKey` in (?) and `related_table`.`deleted_at` is null
|
||||
```
|
||||
86
Career/Others/Laravel tips.md
Normal file
86
Career/Others/Laravel tips.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
created: 2025-01-31 10:42
|
||||
updated: 2025-07-04 07:36
|
||||
---
|
||||
### Dynamic Tenancy Scoping
|
||||
|
||||
BelongsToRelation Trait
|
||||
```php
|
||||
trait BelongsToRelation
|
||||
{
|
||||
public static function bootBelongsToRelation(): void
|
||||
{
|
||||
if (static::belongsDirectlyToRelation()) {
|
||||
static::addGlobalScope(new RelationScope());
|
||||
return;
|
||||
}
|
||||
|
||||
static::addGlobalScope(new RelationThroughScope());
|
||||
}
|
||||
|
||||
public static function belongsDirectlyToRelation(): bool
|
||||
{
|
||||
return !static::getRelationThroughRelationship();
|
||||
}
|
||||
|
||||
abstract public static function getRelationThroughRelationship(): ?string;
|
||||
|
||||
public function relation(): BelongsTo
|
||||
{
|
||||
return $this->belongsTo(Relation::class);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
RelationScope
|
||||
```php
|
||||
|
||||
class RelationScope implements Scope
|
||||
{
|
||||
public function apply(Builder $builder, Model $model): void
|
||||
{
|
||||
if (!Bouncer::inRelationScope()) {
|
||||
return;
|
||||
}
|
||||
|
||||
$builder->where($model->qualifyColumn('relation_id'), Bouncer::getRelationId());
|
||||
|
||||
if (method_exists($model, 'modifyRelationScope')) {
|
||||
$model->modifyRelationScope($builder);
|
||||
}
|
||||
}
|
||||
|
||||
public function extend(Builder $builder): void
|
||||
{
|
||||
$builder->macro('withoutRelationScope', function (Builder $builder) {
|
||||
return $builder->withoutGlobalScope($this);
|
||||
});
|
||||
|
||||
$builder->macro('withOutsideRelationScope', function (Builder $builder, string $relations) {
|
||||
return $builder->with([$relations => fn($query) => $query->withoutWarehouseScope()]);
|
||||
});
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
RelationThroughScope
|
||||
```php
|
||||
class RelationThroughScope implements Scope
|
||||
{
|
||||
public function apply(Builder $builder, Model $model): void
|
||||
{
|
||||
if (!Bouncer::inRelationScope()) {
|
||||
return;
|
||||
}
|
||||
|
||||
$builder->whereHas($builder->getModel()->getRelationThroughRelationship());
|
||||
}
|
||||
|
||||
public function extend(Builder $builder): void
|
||||
{
|
||||
$builder->macro('withoutRelationScope', function (Builder $builder) {
|
||||
return $builder->withoutGlobalScope($this);
|
||||
});
|
||||
}
|
||||
}
|
||||
```
|
||||
9
Career/Others/Max Children.md
Normal file
9
Career/Others/Max Children.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
created: 2025-03-26 11:35
|
||||
updated: 2025-07-04 06:45
|
||||
---
|
||||
```bash
|
||||
sudo grep 'seems busy' /var/log/php8.3-fpm.log
|
||||
```
|
||||
|
||||
#PHP #bash #grep
|
||||
12
Career/Others/New Laravel.md
Normal file
12
Career/Others/New Laravel.md
Normal file
@@ -0,0 +1,12 @@
|
||||
- [ ] Change font
|
||||
- [ ] Add flare
|
||||
- [ ] Enforce morphmap
|
||||
- [ ] Add the mixins
|
||||
- [ ] Add laravel actions
|
||||
- [ ] Add eslint
|
||||
- [ ] Add laravel deployment actions
|
||||
- [ ] barryvdh/laravel-debugbar
|
||||
- [ ] driftingly/rector-laravel
|
||||
- [ ] staudenmeir/eloquent-has-many-deep
|
||||
- [ ] Add telescope
|
||||
|
||||
16
Career/Others/Nginx.md
Normal file
16
Career/Others/Nginx.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
created: 2025-07-03 10:19
|
||||
updated: 2025-07-03 10:35
|
||||
---
|
||||
## Header to Big
|
||||
Add
|
||||
```bash
|
||||
location ~ \.php$ {
|
||||
include fastcgi_params;
|
||||
# Bla bla
|
||||
fastcgi_buffers 16 16k;
|
||||
fastcgi_buffer_size 32k;
|
||||
}
|
||||
```
|
||||
|
||||
After
|
||||
35
Career/Others/Nicer Maintenance Mode.md
Normal file
35
Career/Others/Nicer Maintenance Mode.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
created: 2025-03-12 14:12
|
||||
updated: 2025-07-04 07:25
|
||||
tags:
|
||||
- Laravel
|
||||
---
|
||||
|
||||
|
||||
```bash
|
||||
php artisan down --render="errors::maintenance"
|
||||
```
|
||||
|
||||
```bash
|
||||
php artisan vendor:publish --tag=laravel-errors
|
||||
```
|
||||
|
||||
```
|
||||
touch ./resources/views/errors/maintenance.blade.php
|
||||
```
|
||||
|
||||
``` php maintenance.blade.php
|
||||
@extends('errors.minimal')
|
||||
|
||||
@section('title', __('Planned Maintenance'))
|
||||
@section('message', __('Planned Maintenance'))
|
||||
@section('description', __('We will be back in a few minutes.'))
|
||||
```
|
||||
|
||||
``` php minimal.blade.php
|
||||
@hasSection('code')
|
||||
<div class="px-4 text-lg text-gray-500 border-r border-gray-400 tracking-wider">
|
||||
@yield('code')
|
||||
</div>
|
||||
@endif
|
||||
```
|
||||
47
Career/Others/Rector.md
Normal file
47
Career/Others/Rector.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
created: 2025-03-17 14:03
|
||||
updated: 2025-07-04 07:25
|
||||
tags:
|
||||
- Laravel/Packages
|
||||
---
|
||||
|
||||
|
||||
```bash
|
||||
composer require driftingly/rector-laravel && ./vendor/bin/rector
|
||||
```
|
||||
|
||||
```php. rector
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use Rector\Config\RectorConfig;
|
||||
use Rector\Php74\Rector\Closure\ClosureToArrowFunctionRector;
|
||||
use Rector\Php83\Rector\ClassMethod\AddOverrideAttributeToOverriddenMethodsRector;
|
||||
use Rector\TypeDeclaration\Rector\ClassMethod\AddVoidReturnTypeWhereNoReturnRector;
|
||||
use RectorLaravel\Set\LaravelSetList;
|
||||
|
||||
return RectorConfig::configure()
|
||||
->withPaths([
|
||||
// bla bla
|
||||
])
|
||||
->withPhpSets()
|
||||
->withSkip([
|
||||
ClosureToArrowFunctionRector::class,
|
||||
AddOverrideAttributeToOverriddenMethodsRector::class,
|
||||
AddVoidReturnTypeWhereNoReturnRector::class,
|
||||
])
|
||||
->withPreparedSets(
|
||||
deadCode : true,
|
||||
codeQuality : true,
|
||||
typeDeclarations: true,
|
||||
privatization : true,
|
||||
)
|
||||
->withSets([
|
||||
LaravelSetList::LARAVEL_110,
|
||||
LaravelSetList::LARAVEL_CODE_QUALITY,
|
||||
LaravelSetList::LARAVEL_ELOQUENT_MAGIC_METHOD_TO_QUERY_BUILDER,
|
||||
LaravelSetList::LARAVEL_CONTAINER_STRING_TO_FULLY_QUALIFIED_NAME,
|
||||
LaravelSetList::LARAVEL_COLLECTION,
|
||||
]);
|
||||
```
|
||||
43
Career/Others/Untitled.md
Normal file
43
Career/Others/Untitled.md
Normal file
@@ -0,0 +1,43 @@
|
||||
```bash
|
||||
php artisan make:command AuditDependenciesCommand
|
||||
```
|
||||
|
||||
```php
|
||||
<?php
|
||||
|
||||
namespace App\Console\Commands;
|
||||
|
||||
use Exception;
|
||||
use Illuminate\Console\Command;
|
||||
use Illuminate\Support\Facades\Process;
|
||||
use Spatie\FlareClient\Enums\MessageLevels;
|
||||
use Spatie\LaravelIgnition\Facades\Flare;
|
||||
|
||||
class AuditDependenciesCommand extends Command
|
||||
{
|
||||
protected $signature = 'app:audit-dependencies';
|
||||
|
||||
public function handle(): void
|
||||
{
|
||||
$composer = Process::run('composer audit');
|
||||
|
||||
if (!blank($composer->output())) {
|
||||
$this->warn('Composer audit found vulnerabilities');
|
||||
Flare::glow('Composer audit found vulnerabilities', MessageLevels::WARNING, ['output' => $composer->output()]);
|
||||
Flare::report(new Exception('Composer audit found vulnerabilities'));
|
||||
}
|
||||
|
||||
$npm = Process::run('npm audit');
|
||||
|
||||
if (trim($npm->output()) !== "found 0 vulnerabilities") {
|
||||
$this->warn('NPM audit found vulnerabilities');
|
||||
Flare::glow('NPM audit found vulnerabilities', MessageLevels::WARNING, ['output' => $npm->output()]);
|
||||
Flare::report(new Exception('NPM audit found vulnerabilities'));
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```php in kernel
|
||||
$schedule->command(\App\Console\Commands\AuditDependenciesCommand::class)->daily();
|
||||
```
|
||||
13
Career/Projects/AI/AI.md
Normal file
13
Career/Projects/AI/AI.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
created: 2025-07-09 10:20
|
||||
updated: 2025-07-09 10:20
|
||||
---
|
||||
Starting point:
|
||||
<https://github.com/snwfdhmp/awesome-gpt-prompt-engineering>
|
||||
|
||||
<https://m.youtube.com/watch?v=8omTe58MNQE>
|
||||
<https://docs.text-gen.com/>
|
||||
|
||||
[[The Proof Reader]]
|
||||
|
||||
MOdels /s
|
||||
11
Career/Projects/Model cache/Model cache.md
Normal file
11
Career/Projects/Model cache/Model cache.md
Normal file
@@ -0,0 +1,11 @@
|
||||
A cache tied to the model, is automatically clear when saving. This allows for caching without much thinking about cache invalidation.
|
||||
## Usage
|
||||
Call the model cache method on the model to access it
|
||||
## Todo
|
||||
- [x] Create a class which implements the cache methods and tags all caches. ✅ 2023-10-28
|
||||
- [x] Create a trait which allows for access to this cache and clears is on saved. ✅ 2023-10-28
|
||||
- [x] Add readme about usage. ✅ 2023-11-05
|
||||
- [ ] Allow for the adding of other tags, so the cache can store values dependent on multiple models.
|
||||
- [ ] Make the cache macroable so complex callbacks and tag configurations can defined just once. Add a cache()->toArray() example.
|
||||
- [ ] Add a class factory as a place to store these macros.
|
||||
|
||||
9
Career/Projects/Overbuild Laravel/Overbuild Laravel.md
Normal file
9
Career/Projects/Overbuild Laravel/Overbuild Laravel.md
Normal file
@@ -0,0 +1,9 @@
|
||||
A attempt to split Laravel into domains and modules to support large projects without creating a ball of mud.
|
||||
## Structure
|
||||
The app folder has been removed and instead of that there are multiple folders in to root. Each resembling the app folder.
|
||||
|
||||
These folders are different domains. Pieces of the overal system that are or could be loosly coupled. Information exchange between these domains must use events or by specifically designated services.
|
||||
|
||||
Events are used to lat subscribers from any domain know something happened and it's up to that domain to die with that information what is want.
|
||||
|
||||
Service are used to query and command other domains.
|
||||
90
Career/Resources/Don't make me think.md
Normal file
90
Career/Resources/Don't make me think.md
Normal file
@@ -0,0 +1,90 @@
|
||||
>
|
||||
## Don't Make Me Think
|
||||
The goal is not to make an interface that leads to the least amount of clicks, it should be the least amount of thoughts.
|
||||
|
||||
Thinks that make people think are:
|
||||
• Not knowing the meaning of text, so use simple language.
|
||||
• Not knowing what to interact with.
|
||||
|
||||
So things should be self-evident, or at least self-explanatory.
|
||||
|
||||
## How We Really Use the Web
|
||||
|
||||
Web pages are not read they are scanned. People need to find something, they dont need to read everything and are good at scanning.
|
||||
|
||||
Also people look for a reasonably good option instead of the best one. They are in a hurry, there is little penalty for guessing wrong.
|
||||
|
||||
Users are there to muddle through.
|
||||
## Billboard Design 101
|
||||
|
||||
Some quick conventions
|
||||
• Make use of conventions
|
||||
- Use visual hierarchy .1'm portent things are prominent.
|
||||
• Related things are visually related
|
||||
• Nested things are a part of • Break up pages into areas
|
||||
• Show what is clickable.
|
||||
• Eliminate visual noise
|
||||
• Format to support scanning
|
||||
|
||||
## Animal, Vegetable, or Mineral?
|
||||
|
||||
Navigation becomes difficult by not knowing where to click, it number of clicks is less relevant.
|
||||
|
||||
Omit needless words
|
||||
|
||||
Keep text short or hidden in order to:
|
||||
- reduce noise
|
||||
- make use full content more prominent
|
||||
- make pages shorter
|
||||
|
||||
The same holds for instructions, people only read them if muddeling through does not work.
|
||||
|
||||
## Street Signs and Breadcrumbs
|
||||
Some users are search dominant others are link dominant.
|
||||
|
||||
After a browsing click, the user should know it was the right click.
|
||||
|
||||
Compared to normal navigation web browsing gives no sense of scale, direction or location. This needs to be added.
|
||||
Away to get this is, persistent navigation. Which should include, the site identification, its sections, utilities and a search.
|
||||
|
||||
Give users to option to limit the scope after they have seen the scope is to wide.
|
||||
|
||||
Due to search engines, people are dropped randomly in a site. Make sure that they know where they are.
|
||||
Site > Page name > Sections > Local navigation > you are here > Search
|
||||
|
||||
## The Big Bang Theory of Web Design
|
||||
|
||||
Things a homepage needs to do:
|
||||
- Site identity and mission, where am I?
|
||||
- Hierarchy, where to go next.
|
||||
- Search, help?
|
||||
- Teases, hint at the good stuff
|
||||
- Content promos, the top content
|
||||
- Feature promos, the top sections
|
||||
- Timely content, the reason to come regularly
|
||||
- Deals
|
||||
- Shortcuts, utility
|
||||
- Registration, utility
|
||||
|
||||
Some abstract objectives:
|
||||
- Show people what they want to see or how to get there.
|
||||
- Expose people to new stuff.
|
||||
- Establish credit-lily and trust.
|
||||
|
||||
Given that every has an option about what needs to be on the frontpage. Remember them the page is for the user, not for them.
|
||||
|
||||
While doing all this, keep in mind the first questions:
|
||||
- What is this?
|
||||
- What do they have here?
|
||||
- what can I do here?
|
||||
- Why should I be here?
|
||||
|
||||
## Usability Testing on 10 Cents a Day
|
||||
|
||||
Testing should be done during the entire design stage.
|
||||
Don't use focus group, one is for testing peoples feelings. Usability is about a single person getting the site.
|
||||
|
||||
See the rest should we even start testing.
|
||||
## Mobile; It's not just a City in Alabama Anymore
|
||||
|
||||
There is not much difference between desktop and mobile, people just read even less and scroll faster.
|
||||
Binary file not shown.
@@ -0,0 +1,27 @@
|
||||
Collection of objects clustered together for the purpose of data changes. Designed to keep data transactionally consistent.
|
||||
|
||||
> Like splitting orders into orderlines. Maybe view them as very closely coupled models/ entities. Something where the main model owns the interface with the world. So the root entity
|
||||
|
||||
A design consideration is the size of the aggregate, as storing race conditions become a problem. To find a boundary consider the need for consistency, if transactional consistency is needed it is likely within the aggregate. It could well be that most aggregate consist of a single entity, the root.
|
||||
|
||||
> If eventual consistency is fine. Maybe store this in another aggregat and couple them using a event.
|
||||
|
||||
Not every use case that modifies multiple aggregates warrants the combining of the aggregates into a single one. First find out if eventual consistency is acceptable. Domain experts are often more comfortable with eventual or delayed consistency. This happens in the real world all the time.
|
||||
|
||||
>But don't forget to tell them!!!
|
||||
|
||||
>A way to force an aggregate is to keep its relation methods private. Keeping it's interaction going through the root model.
|
||||
|
||||
Or consider single use actions / commands. There are however reasons for changing multiple aggregates in a single transaction.
|
||||
- User Interface Convenience, think bulk editsor simply complex interfaces. This does not mean all the aggrates involved should be a single aggregate.
|
||||
- Not having the technical means to do eventual consistency. Or introducing it for a single case.
|
||||
- Global transactions Transactions spanning multiple domain
|
||||
- Database preformance. All the data is there, just use it.
|
||||
|
||||
## Implementing Eventual Consistency
|
||||
An event is published which then wakes some listener. While this is happening in the background, the user may need to be informed by some visual indication of the system stil being in transit.
|
||||
> Frame automation like a college doing the work for you but it may take some time before they get to it.
|
||||
|
||||
> Build in a version attribute into each Roof Entity. This way depenancies are clear and we can speak of a real version.
|
||||
|
||||
No dependency injection into an aggregate.
|
||||
23
Career/Resources/Laracast/Eloquent Performance Patterns.md
Normal file
23
Career/Resources/Laracast/Eloquent Performance Patterns.md
Normal file
@@ -0,0 +1,23 @@
|
||||
### Getting one recode from a has many relation
|
||||
addSelect(['value_name' => Model::whereColumn('a','table.b')->take(1)])
|
||||
|
||||
|
||||
|
||||
### Dynamic Relationships Using Subqueries
|
||||
The relation column can be added using a addSelect
|
||||
|
||||
### Calculate Totals Using Conditional Aggregates
|
||||
case exists
|
||||
|
||||
### Optimize Circular Relationships
|
||||
Manual set relation to the model instead of loading it again
|
||||
|
||||
### Getting LIKE to use an Index
|
||||
Dont use wildcards on both sides
|
||||
|
||||
### Use Unions to Run Queries Independently
|
||||
Where in
|
||||
derived table
|
||||
find users by x
|
||||
union
|
||||
find users by y
|
||||
@@ -0,0 +1 @@
|
||||
bla
|
||||
@@ -0,0 +1,4 @@
|
||||
You can make most populair articles with redis, it has (sorted) lists, hashmap etc.
|
||||
|
||||
Move stuff you want to cache in a repository, maybe with a non cached version.
|
||||
|
||||
19
Career/Resources/Laracast/Modular Laravel.md
Normal file
19
Career/Resources/Laracast/Modular Laravel.md
Normal file
@@ -0,0 +1,19 @@
|
||||
He put everything in a modules folder / namespace. Inside a module the default Laravel structure is use.
|
||||
|
||||
Each module gets a service provider, with a loadMigrationsFrom, mergeConfigFrom and registers other providers.
|
||||
|
||||
Each model gets a route service provider.
|
||||
Each model gets a event service provider.
|
||||
|
||||
Tests are put in the modules and bound in the phpunit.xml. FYI starts are followed
|
||||
'/modules/\*/Test' works. Also add modules specific base test case.
|
||||
|
||||
To bind factory, define model and newFactory method.
|
||||
|
||||
When you need to use models from other modules, instead use Data Transfer Objects which can then be used to encapsulate behaviour.
|
||||
|
||||
Make your dto's readonly and enforce properties to be primitives. When breaking a boundary a easy fix would be to make placeholder class a module and inject it into the other module.
|
||||
|
||||
Then behaviour is put into actions.
|
||||
|
||||
To uncoupling make dto's from your models and start moving all the things you need into those dtos
|
||||
107
Career/Resources/Mac Setup.md
Normal file
107
Career/Resources/Mac Setup.md
Normal file
@@ -0,0 +1,107 @@
|
||||
## TODO's
|
||||
Tweak spotlight settings
|
||||
|
||||
```bash
|
||||
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
|
||||
```
|
||||
|
||||
### Add Spacers to Dock
|
||||
```bash
|
||||
defaults write com.apple.dock persistent-apps -array-add '{tile-data={}; tile-type="spacer-tile";}' && killall Dock
|
||||
```
|
||||
Small space
|
||||
```bash
|
||||
defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="small-spacer-tile";}' && killall Dock
|
||||
```
|
||||
|
||||
<https://github.com/nicoverbruggen/phpmon>
|
||||
|
||||
Xd
|
||||
Amphetamine
|
||||
AnkerWork
|
||||
Bitwarden
|
||||
DBngin
|
||||
Firefox
|
||||
Chrome
|
||||
Handbrake
|
||||
ImageOptim
|
||||
iTerm
|
||||
ohMyshell
|
||||
LM Studio
|
||||
Logi Options+
|
||||
Microsoft Suite
|
||||
Obsidian
|
||||
Ollama
|
||||
PHP Monitor
|
||||
PhpStorm
|
||||
Pocket Casts
|
||||
Postman
|
||||
Rectangle
|
||||
Second Cock
|
||||
Signal
|
||||
Stretchly
|
||||
Sublime Text
|
||||
SitchHosts
|
||||
TablePlus
|
||||
Vs Code
|
||||
|
||||
### Brew
|
||||
antiword jpegoptim node@22
|
||||
aom jq npth
|
||||
apr krb5 nspr
|
||||
apr-util leptonica nss
|
||||
argon2 libarchive oniguruma
|
||||
aspell libassuan openexr
|
||||
autoconf libavif openjpeg
|
||||
awscli libb2 openldap
|
||||
bash libde265 openssl@1.1
|
||||
brotli libdeflate openssl@3
|
||||
c-ares libevent optipng
|
||||
ca-certificates libffi p11-kit
|
||||
cairo libgcrypt packer
|
||||
capstone libgpg-error pango
|
||||
certifi libheif pcre2
|
||||
cffi libidn php
|
||||
composer libidn2 php@7.4
|
||||
coreutils libksba php@8.1
|
||||
cryptography liblqr php@8.2
|
||||
curl libnghttp2 php@8.3
|
||||
dnsmasq libomp pinentry
|
||||
dog libpng pixman
|
||||
dumps libpq pkgconf
|
||||
fontconfig libraw pngquant
|
||||
freetds libsodium poppler
|
||||
freetype libssh pycparser
|
||||
fribidi libssh2 python-certifi
|
||||
fswatch libtasn1 python-packaging
|
||||
gd libtiff python@3.10
|
||||
gdbm libtool python@3.11
|
||||
gettext libunistring python@3.12
|
||||
gh libusb python@3.13
|
||||
ghostscript libuv python@3.9
|
||||
giflib libvmaf readline
|
||||
gifsicle libx11 redis
|
||||
git libxau rtmpdump
|
||||
git-lfs libxcb shared-mime-info
|
||||
glib libxdmcp sqlite
|
||||
gmp libxext svgo
|
||||
gnupg libxrender terraform
|
||||
gnutls libzip tesseract
|
||||
gpgme little-cms2 tesseract-lang
|
||||
graphite2 luajit tidy-html5
|
||||
grep lz4 tldr
|
||||
harfbuzz lzo tree
|
||||
highway m4 unbound
|
||||
htop mackup unixodbc
|
||||
httpie mailhog webp
|
||||
icu4c@75 mas wget
|
||||
icu4c@76 mpdecimal wp-cli
|
||||
imagemagick ncurses wrk
|
||||
imagemagick@6 net-snmp x265
|
||||
imath nettle xorgproto
|
||||
jasper nginx xz
|
||||
jbig2dec node youtube-dl
|
||||
jpeg-turbo node@16 zstd
|
||||
jpeg-xl node@18
|
||||
|
||||
#Snippets
|
||||
4
Career/Resources/Max Children.md
Normal file
4
Career/Resources/Max Children.md
Normal file
@@ -0,0 +1,4 @@
|
||||
```bash
|
||||
sudo grep 'seems busy' /var/log/php8.3-fpm.log
|
||||
```
|
||||
#Snippets
|
||||
13
Career/Resources/New Laravel.md
Normal file
13
Career/Resources/New Laravel.md
Normal file
@@ -0,0 +1,13 @@
|
||||
- [ ] Change font
|
||||
- [ ] Add flare
|
||||
- [ ] Enforce morphmap
|
||||
- [ ] Add the mixins
|
||||
- [ ] Add laravel actions
|
||||
- [ ] Add eslint
|
||||
- [ ] Add laravel deployment actions
|
||||
- [ ] barryvdh/laravel-debugbar
|
||||
- [ ] driftingly/rector-laravel
|
||||
- [ ] staudenmeir/eloquent-has-many-deep
|
||||
- [ ] Add telescope
|
||||
|
||||
#Snippets
|
||||
13
Career/Resources/Nginx.md
Normal file
13
Career/Resources/Nginx.md
Normal file
@@ -0,0 +1,13 @@
|
||||
### Header to big
|
||||
Add
|
||||
```bash
|
||||
location ~ \.php$ {
|
||||
include fastcgi_params;
|
||||
# Bla bla
|
||||
fastcgi_buffers 16 16k;
|
||||
fastcgi_buffer_size 32k;
|
||||
}
|
||||
```
|
||||
|
||||
#nginx
|
||||
#Snippets
|
||||
3
Career/Resources/Packages/Holidays.md
Normal file
3
Career/Resources/Packages/Holidays.md
Normal file
@@ -0,0 +1,3 @@
|
||||
<https://github.com/spatie/holidays>
|
||||
|
||||
#Carbon #TimeKeeping
|
||||
6
Career/Resources/Packages/Laravel Deploy Operations.md
Normal file
6
Career/Resources/Packages/Laravel Deploy Operations.md
Normal file
@@ -0,0 +1,6 @@
|
||||
https://github.com/TheDragonCode/laravel-deploy-operations
|
||||
```bash
|
||||
composer require dragon-code/laravel-deploy-operations && \
|
||||
php artisan vendor:publish --tag=config --provider="DragonCode\LaravelDeployOperations\ServiceProvider"
|
||||
|
||||
```
|
||||
@@ -0,0 +1 @@
|
||||
https://ollieread.com/articles/a-minimal-identity-map-for-laravel-eloquent
|
||||
3
Career/Resources/Packages/Recurr.md
Normal file
3
Career/Resources/Packages/Recurr.md
Normal file
@@ -0,0 +1,3 @@
|
||||
<https://github.com/simshaun/recurr>
|
||||
|
||||
#Carbon #TimeKeeping
|
||||
3
Career/Resources/Packages/Rewind.md
Normal file
3
Career/Resources/Packages/Rewind.md
Normal file
@@ -0,0 +1,3 @@
|
||||
<https://github.com/avocet-shores/laravel-rewind>
|
||||
|
||||
#Versioning #packages
|
||||
3
Career/Resources/Packages/Rich Test Laravel.md
Normal file
3
Career/Resources/Packages/Rich Test Laravel.md
Normal file
@@ -0,0 +1,3 @@
|
||||
<https://github.com/tonysm/rich-text-laravel?tab=readme-ov-file>
|
||||
|
||||
#WYSIWYG
|
||||
42
Career/Resources/Rector.md
Normal file
42
Career/Resources/Rector.md
Normal file
@@ -0,0 +1,42 @@
|
||||
```bash
|
||||
composer require driftingly/rector-laravel && ./vendor/bin/rector
|
||||
```
|
||||
|
||||
```php. rector
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use Rector\Config\RectorConfig;
|
||||
use Rector\Php74\Rector\Closure\ClosureToArrowFunctionRector;
|
||||
use Rector\Php83\Rector\ClassMethod\AddOverrideAttributeToOverriddenMethodsRector;
|
||||
use Rector\TypeDeclaration\Rector\ClassMethod\AddVoidReturnTypeWhereNoReturnRector;
|
||||
use RectorLaravel\Set\LaravelSetList;
|
||||
|
||||
return RectorConfig::configure()
|
||||
->withPaths([
|
||||
// bla bla
|
||||
])
|
||||
->withPhpSets()
|
||||
->withSkip([
|
||||
ClosureToArrowFunctionRector::class,
|
||||
AddOverrideAttributeToOverriddenMethodsRector::class,
|
||||
AddVoidReturnTypeWhereNoReturnRector::class,
|
||||
])
|
||||
->withPreparedSets(
|
||||
deadCode : true,
|
||||
codeQuality : true,
|
||||
typeDeclarations: true,
|
||||
privatization : true,
|
||||
)
|
||||
->withSets([
|
||||
LaravelSetList::LARAVEL_110,
|
||||
LaravelSetList::LARAVEL_CODE_QUALITY,
|
||||
LaravelSetList::LARAVEL_ELOQUENT_MAGIC_METHOD_TO_QUERY_BUILDER,
|
||||
LaravelSetList::LARAVEL_CONTAINER_STRING_TO_FULLY_QUALIFIED_NAME,
|
||||
LaravelSetList::LARAVEL_COLLECTION,
|
||||
]);
|
||||
```
|
||||
|
||||
#Snippets
|
||||
#PHP
|
||||
8
Career/Resources/Switch to new locaization package.md
Normal file
8
Career/Resources/Switch to new locaization package.md
Normal file
@@ -0,0 +1,8 @@
|
||||
|
||||
```bash
|
||||
composer require dartmoon/laravel-localized-routes && php artisan vendor:publish --provider="Dartmoon\LaravelLocalizedRoutes\LaravelLocalizedRoutesServiceProvider"
|
||||
```
|
||||
|
||||
Switch out **Route::localized** for **Route::localize**
|
||||
|
||||
Current route names are no longer prefixed with local
|
||||
@@ -0,0 +1 @@
|
||||
Not much to say.
|
||||
@@ -0,0 +1,9 @@
|
||||
Critical documents for building a software product include:
|
||||
|
||||
- Objectives: This document outlines the specific needs to be met, along with goals, constraints, and priorities.
|
||||
- Specifications: This document includes both the manual and performance specifications. It is typically one of the first documents generated and one of the last to be finalized.
|
||||
- Schedule
|
||||
- Budget: This document not only serves as a constraint but also acts as a tool to drive decision-making and the creation and management of policies.
|
||||
- Organization Chart: This document defines the hierarchical structure of the project team, highlighting the roles and responsibilities of each member.
|
||||
- Space Allocations: This document determines how physical or virtual spaces will be allocated for different project activities and resources.
|
||||
- Estimate, forecast, prices.
|
||||
@@ -0,0 +1,11 @@
|
||||
In most projects, the first system build is barely useable. The question is not weither to build this pilot system, you will anyway. The question is weither or not to expose the customer to this system. Doing so wil result in distractions to the builder while they redesign and a bad reputation. So plan to throw pilots away, you will anyhow.
|
||||
|
||||
Change will happen and thus should be embrassed. To do this the ability to change should be build in the system. And in the team.
|
||||
|
||||
The last reason to throw away is that as a system is used, fixed, maintanced and expanded. Entropy will increase ountill the system devolves into unmaintanable obsulasence
|
||||
|
||||
In most projects, the initial system build is often not fully functional. The decision to build this pilot system is not a question, as it is usually necessary. However, the important consideration is whether or not to expose the customer to this system. Doing so can result in distractions for the builders as they work on redesigning. Also this will lead to a negative reputation. So plan to throw pilots away, you will anyhow.
|
||||
|
||||
Change is an inherent part of any project, and it should be embraced. It is crucial to incorporate the ability to adapt and accommodate changes both in the system itself and within the team.
|
||||
|
||||
Another compelling reason to dispose of systems is that over time, as the system is used, fixed, maintained, and expanded, entropy increases. This gradual increase in disorder and complexity can render the system obsolete and extremely challenging to maintain.
|
||||
@@ -0,0 +1 @@
|
||||
Is about the need for good tools and examples from decade ago.
|
||||
@@ -0,0 +1 @@
|
||||
Schedule slippage is not typically caused by large events, as those events often prompt immediate action. It is the accumulation of unnoticed small issues that leads to delays. Hence, the implementation of milestones becomes essential.
|
||||
@@ -0,0 +1,16 @@
|
||||
User-facing documentation should include the following;
|
||||
|
||||
1. How to use a program:
|
||||
- Purpose: Clearly state the main function of the program.
|
||||
- Environment: Specify the necessary hardware and configurations.
|
||||
- Domain and Range: Define the input and output parameters.
|
||||
- Implemented Functions and Algorithms: Explain the precise workings of the program.
|
||||
- Options: Outline available customization or settings.
|
||||
- Running Time: Provide information on the program's performance.
|
||||
- Accuracy and Checking: Describe the program's reliability and verification methods.
|
||||
2. How to validate a program: Present a brief demonstration to prove the system's functionality, including:
|
||||
- The main use case.
|
||||
- An edge case where the system barely functions.
|
||||
- An alternative edge case to show the system's capabilities.
|
||||
3. How to modify a program:
|
||||
- Provide instructions on making changes or updates to the program.
|
||||
@@ -0,0 +1,13 @@
|
||||
The reasons why estimations often go awry are multifaceted. Firstly, estimating techniques are often poor and can fail to accurately predict the time and resources required for a project. Furthermore, these techniques can confuse effort with progress and assume that men and months are interchangeable, which is not always the case.
|
||||
|
||||
Another reason why estimations can go wrong is due to uncertainty, which can lead to a lack of stubbornness in adhering to schedules. Additionally, schedules are often not monitored, and schedule slippage is often countered with increased manpower. This can result in a further decrease in productivity due to communication issues and the time it takes for new team members to become familiar with the project.
|
||||
|
||||
Programmers are often optimistic, perhaps due to their youth, and assume that there will be little implementation difficulty in their work.
|
||||
|
||||
Due to the absence of productivity and bug incidence figures, estimates can be inherently poor. However, in such cases, programmers should stick to their estimations rather than engaging in wishful thinking.
|
||||
|
||||
The man-month measure is only useful when no communication is needed between workers. However, communication is necessary for effective project management and can become increasingly difficult as the number of workers increases. The effort of communication must be factored into the estimation process, as training grows linearly with the number of workers and intercommunication grows exponentially.
|
||||
|
||||
System tests are the most challenging part of a project and are often done last, resulting in the greatest cost. A recommended schedule for a project would be to allocate one-third of the time to planning, one-sixth to coding, one-quarter to component testing, and one-quarter to system testing.
|
||||
|
||||
When faced with schedule slippage, it is important to ask whether the original estimate was too low locally or universally. The cost of adding more men is N times the training, and communication can become exponentially harder. Finally, the number of men required is dependent on the number of individual subtasks.
|
||||
@@ -0,0 +1,12 @@
|
||||
While small teams of 10x developers are preferred, even these teams cannot be as productive as very large teams. However, by dividing large tasks into smaller segments and utilizing teams of specialized people, productivity can be increased.
|
||||
|
||||
Mills proposes that large tasks should be divided into smaller segments, each dealt with by a team of specialists, similar to a surgical team. The team should consist of the following roles:
|
||||
|
||||
- **The Surgeon (Chief Programmer):** Defines the functional and performance specifications, codes, tests, and writes documentation.
|
||||
- **The Copilot:** Works closely with the surgeon and performs similar tasks but with less experimentation.
|
||||
- **The Administrator:** Has the final say on personnel, teams, and expenses but should not spend any time dealing with them. This person can serve multiple teams.
|
||||
- **The Editor:** Responsible for documentation, takes drafts from the surgeon, and reworks them into a coherent whole.
|
||||
- **Secretaries:** Assist the administrator and editor with correspondence and non-product files.
|
||||
- **The Program Clerk:** Maintains technical records in a programming product library, ensuring all information is available to the team, and relieves programmers of clerical chores.
|
||||
- **The Toolsmith:** Ensures the surgeon has the necessary tools and assists with testing by supplying data and planning test sequences.
|
||||
- **The Language Lawyer:** A specialist in language or framework who can serve multiple surgeons.
|
||||
@@ -0,0 +1,5 @@
|
||||
### Conceptual Integrity
|
||||
|
||||
According to Brooks, the most crucial factor to consider in system design is to implement a single set of design ideas and to omit anomalous features and improvements, regardless of their quality. To achieve this, a single or a few like-minded individuals should be responsible for the design, which limits the number of people who can work on the system. However, Brooks offers two solutions to this limitation. The first is to separate the architecture from implementation, and the second is to form teams as described in previous chapters.
|
||||
|
||||
The system architect's primary responsibility should be to prioritize the user's needs above all other considerations.
|
||||
@@ -0,0 +1,3 @@
|
||||
An architect's initial work tends to be spare and clean due to their lack of knowledge and experience, which causes them to exercise restraint. However, as they gain more experience and knowledge, they encounter numerous frills and embellishments that they may want to incorporate into their designs in the future. This can lead to the creation of overly complex and risky systems, making the second iteration of a design the most dangerous one.
|
||||
|
||||
To avoid this danger, it's important to keep asking yourself whether any additional compute, time, or effort is truly necessary for the system to function effectively. By maintaining a focus on simplicity and avoiding the temptation to add unnecessary features, an architect can create a robust and efficient system that meets the needs of its users without introducing unnecessary complexity or risk.
|
||||
@@ -0,0 +1,5 @@
|
||||
The manual, or written specifications, is an essential tool for the implementation of a system. Any changes made during the implementation should be dated and quantified to ensure that the implementer knows what has changed and which decisions supersede others.
|
||||
|
||||
The manual should describe how the user sees and interacts with the system but not the underlying technical details, which is the responsibility of the implementer. However, the architect should be able to provide guidance on the implementation.
|
||||
|
||||
When writing the manual, it's important to choose a formal or informal tone and clearly mark any secondary tone. During the implementation, the architecht should keep a log of even minor complaints and questions and resolve them in bulk during a meeting.
|
||||
@@ -0,0 +1,20 @@
|
||||
Communication between programs should occur through as many channels as possible.
|
||||
|
||||
- Informal communication: Clear definitions of intergroup dependencies can encourage informal communication among teams.
|
||||
- Meetings: Regular meetings can be held, where one team or programmer presents technical details. This can help to identify and resolve misunderstandings.
|
||||
- Project Workbook: A formal project workbook can be created to document the technical details of the project and serve as a reference for all teams involved.
|
||||
|
||||
## Project Workbook
|
||||
|
||||
The project workbook should define a structured framework for organizing all documents related to the project. It should include, at a minimum, the following sections:
|
||||
|
||||
- Objectives
|
||||
- External Specifications
|
||||
- Interface Specifications
|
||||
- Technical Standards
|
||||
- Internal Specifications
|
||||
- Administrative Memoranda
|
||||
|
||||
One of the challenges of using a project workbook is that it requires everyone involved to read it. Therefore, it should be easily accessible, and users should be able to quickly see any changes made to the document, without having to re-read the entire document.
|
||||
|
||||
However, not everyone may be comfortable with this approach, as some may prefer to shield individuals from unnecessary complexity. This approach requires that all interfaces are complete and that the necessary documentation is in place.
|
||||
@@ -0,0 +1 @@
|
||||
Not much to say.
|
||||
@@ -0,0 +1 @@
|
||||
Deals with space constraints, which is not really a problem any more.
|
||||
@@ -0,0 +1,13 @@
|
||||
[[Ch.1 The Tarpit]]
|
||||
[[Ch.2 The Mythical Man Month]]
|
||||
The chapter discusses the reasons why estimations often go wrong, including poor estimating techniques, confusion between effort and progress, and optimistic assumptions. Uncertainty, lack of schedule monitoring, and adding manpower to counter schedule slippage can further decrease productivity due to communication issues. The man-month measure is only useful when no communication is needed between workers, and the effort of communication must be factored into the estimation process. System tests are the most challenging part of a project and should be allocated one-quarter of the time. When faced with schedule slippage, it is important to determine if the original estimate was too low locally or universally, as adding more men can be costly and communication can become exponentially harder. The number of men required is dependent on the number of individual subtasks.
|
||||
> In order to improve the accuracy of our estimations, it is crucial to obtain more reliable and precise productivity figures. Specifically, we should focus on gathering data about the amount of time spent on improvement, adjustment, and debugging as compared to the time spent on building.
|
||||
>
|
||||
> So for HGBI we should start labeling ticket correctly.
|
||||
|
||||
### [[Ch.3 The Surgical Team]]
|
||||
The text discusses Mills' proposal for increasing productivity by dividing large tasks into smaller segments and utilising teams of specialised individuals, similar to a surgical team. The proposed team consists of a surgeon or chief programmer, copilot, administrator, editor, secretaries, program clerk, toolsmith, and language lawyer. The text also notes that while small teams of 10x developers are preferred, even they cannot be as productive as very large teams.
|
||||
|
||||
>If we where to do this we would need to split of the secretary and the administrator. Also we need to start having an editor.
|
||||
|
||||
>If we where to do this, we need better communication. Our specialists are being bogged down as they also serve as surgeons or copilots.
|
||||
25
Career/Resources/The Psychology of Design.md
Normal file
25
Career/Resources/The Psychology of Design.md
Normal file
@@ -0,0 +1,25 @@
|
||||
<https://growth.design/psychology/>
|
||||
## Hick's Law
|
||||
|
||||
Hick's Law predicts that the time and the effort it takes to make a decision, increases with the number of options. The more choices, the more time users take to make their decisions.
|
||||
|
||||
> Multiple simple decisions are easier then one large decision. Hence, wizards.
|
||||
> Remove navigation options from single use pages, to don't give people the choice to move away. (Maybe show it as a popup)
|
||||
|
||||
## Confirmation Bias
|
||||
|
||||
People tend to search for, interpret, prefer, and recall information in a way that reinforces their personal beliefs or hypotheses.
|
||||
|
||||
## Priming
|
||||
|
||||
Subtle visual or verbal suggestions help users recall specific information, influencing how they respond. Priming works by activating an association or representation in users short-term memory just before another stimulus or task is introduced.
|
||||
|
||||
## Cognitive Load
|
||||
|
||||
Cognitive load is the total amount of mental effort that is required to complete a task. You can think of it as the processing power needed by the user to interact with a product. If the information that needs to be processed exceeds the user’s ability to handle it, the cognitive load is too high.
|
||||
|
||||
> Similarly to Hick's law, reduce as much as possible.
|
||||
## Random Stuff:
|
||||
### Sniper Links
|
||||
For an email confirmation, generate a link dat send the user to their inbox pre-filtered so they can't start reading emails.
|
||||
`in:anywhere`: it finds the email **even if it's marked as spam**.
|
||||
42
Career/Week 27 30 June – 4 July.md
Normal file
42
Career/Week 27 30 June – 4 July.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
created: 2025-07-04 17:44
|
||||
updated: 2025-07-04 17:44
|
||||
---
|
||||
|
||||
## 1. Highlights & Wins
|
||||
- **Project / Area**: QLS Handling — Deployed touchscreen time-tracking for warehouse staff
|
||||
- **Impact & Metrics**:
|
||||
- Staff onboarded: ~20 employees
|
||||
- Time saved: ~12–15 hrs/week (manual logging + digitization)
|
||||
- Error reduction: ~85% fewer missing or incorrect entries
|
||||
|
||||
- **Project / Area**: QLS Handling — Kicked off API integration with third-party customs data provider
|
||||
- **Impact & Metrics**:
|
||||
- Shipments covered: ~50/day (~250/week)
|
||||
- Time saved: ~20 hrs/week of manual data entry
|
||||
- Error reduction: ~90% fewer data-entry mistakes
|
||||
|
||||
- **Project / Area**: QLS Handling — Led on-site brainstorming session with the warehouse team
|
||||
- **Impact & Metrics**:
|
||||
- Top action items: refine receiving workflow; update inventory labeling; establish daily stand-up
|
||||
- Quick win: new labeling process (~2 hrs/week saved)
|
||||
|
||||
## 2. Challenges & Blockers
|
||||
- **High urgency / Priority shift**: Compressed timeline forced pausing all other projects so I could devote 100% focus to QLS Handling.
|
||||
- **Invoicing-flow complexity**: Need to support 4 major cost types (each with ≥ 2 billing variations) plus an upstream “incident” billing path for transport failures—making schema design and testing particularly intricate.
|
||||
- **Spec dependencies**: Awaiting detailed incident definitions from logistics partners to finalize the upstream incident billing logic.
|
||||
|
||||
## 3. Learnings & Growth
|
||||
- Prepared for AWS Aurora migration: configured the initial Aurora cluster and deepened understanding of its scaling, high-availability, and compatibility features.
|
||||
- (No time this week for a formal skills deep-dive due to urgent QLS Handling priorities.)
|
||||
|
||||
## 4. Collaboration & Mentorship
|
||||
- **Finance Stakeholder Meeting**: Discussed and aligned on the new invoicing flow’s requirements and billing model variations.
|
||||
- **Warehouse Team Sync**: Gathered additional change requests and clarified workflows needed for QLS Handling updates.
|
||||
|
||||
## 5. Next Week’s Goals
|
||||
- [ ] Migrate production database to AWS Aurora and validate performance benchmarks
|
||||
- [ ] Roll out new warehouse software (built over the last half year) to the warehouse team: onboarding & training sessions
|
||||
- [ ] Provide quick bug fixes and support for the new warehouse software as issues arise
|
||||
- [ ] Finalize incident-billing logic once upstream specs arrive
|
||||
- [ ] Conduct QLS integration smoke tests post-launch and triage any issues
|
||||
Reference in New Issue
Block a user