Rita Łyczywek (Małgorzata)

IDE-agnostic tools allow developers to develop Adobe Experience Manager projects without being tied to a specific IDE, increasing flexibility and streamlining tasks. In their illuminating article, Krystian Panek and Dominik Przybył show how standalone CLI tools such as AEM Compose or bash scripts can be can be used with IntelliJ IDEA to automate various Adobe Experience Manager tasks. This article demonstrates how these tools can be used to automate pulling JCR content from an Experience Manager instance to a local codebase, or to execute Groovy scripts on an Experience Manager instance during development. Their article is an excellent resource for Experience Manager developers looking to optimise their daily workflow, and you can check it out by following the link in the comments below. ↓ #Adobe #AdobeExperienceManager #IDE

2

1 komentarz

I'll be talking about building future-proof React applications on the 30th of May in Bucharest. Everyone needs to have a set of principles they follow so they don't have to think about every problem from scratch. I'll tell you how I've been building React applications for the last 8 years. What works. What doesn't. What to focus on to make sure you don't have to rewrite your application every year. Because programming is about solving problems. But engineering is about maintaining those solutions over time.

100

3 komentarze

Developers don't like breaking changes. It's worse if these changes weren't communicated in the first place! Here is a roundup of techniques to consider to make API versioning painless.

5

Developers these days are so darned lazy. And cheap. OK, sorry, that was not fair. Developers have always been lazy and cheap. I was really surprised by this when I started out as a software developer, fresh out of college 25 years ago. I noticed that whenever my more experienced colleagues were asked to add new functionality, the first thing they did was to check if there was pre-existing code that did the job. Preferably free. This blew my mind. But as I thought more about it, it made sense. Especially after I attended a Business Strategy class at Southern Methodist University SMU Cox School of Business. Build vs Buy vs Reuse is a part of Business Strategy. Why build or buy something if it is freely available? When we start with something good-enough that is freely available, we can customize it to our needs. And if it is well-maintained, we get free upgrades. This frees up more time and money for us to build things that no one else can build as well as us, which makes customers very happy. It reduced the TCO (total cost of ownership) of our solutions and it increases our EBITDA, which usually makes investors very happy, which makes the board of directors very happy. So it turns out that developers are not only lazy and cheap, but they are also strategic and there is a lot we can learn from them. Especially when it comes to building Software Product Development Lifecycles. You may be tempted to reject the pre-existing frameworks and build your own because none of them are good enough for you. Newsflash! You might think you are unique and special and nobody is solving the specific kinds of problems you are. Maybe yes, maybe no. You are just as unique as every other snowflake. And while you might be doing something nobody else has done before, you don't need to develop your own SDLC. Think like a developer. Be lazy, cheap and strategic. Start with a pre-existing framework, make use of all the free training available on the market, and customize only what you need to. Your EBITDA will go up and your customers, investors and Board of Directors will be happy. You are welcome.

14

4 komentarze

I didn't expect to say it this soon, but I'm enjoying working with TailwindCSS. I have used it for the AutoProject webapp. And with the help of LLMs, writing TailwindCSS has become quite easy. I often just describe the design I want and ask GPT to come up with the TailwindCSS for it. It works well, most of the times. Just a month or so ago, I talked about how I disliked Tailwind for its very long and verbose CSS classes. Every html element in your code will have a long list of class names to get the required design. I still dislike it, but after trying it more, I felt the productivity gain is worth it. Prior to this, I always preferred writing my own CSS because I wanted the design to be very unique and customized to me. In hindsight, that's still good but it reduced my shipping speed and added unnecessary "figuring it out" and "testing" overhead. I am continuing to write my personal CSS + Component library to factor in that uniqueness, but in the meantime, tailwind looks like an excellent tool to iterate very fast and build great looking UIs. With a stable Tailwind version 4 releasing soon, it looked like the right time to pick it up. In version 4, we can expect: - 10x faster builds - 35% smaller in size - Use of lightning CSS (I'm using this for my personal CSS library too!) - A custom parser that's 2X faster than PostCSS. (They literally designed new data structures to achieve this!) If you have been a skeptic like me, to Tailwind or CSS libraries in general, don't sleep on it. I'm thinking of migrating even TechFlix to TailwindCSS.

26

3 komentarze

Interested in optimizing your development workflow? Our latest blog post explores the ins and outs of leveraging Dev Mode with Payara Micro Maven plugin, guiding you step by step in the creation, running and development of a Payara Micro Maven project in IntelliJ IDEA. Learn how to use key features, such as auto-deploy and live reload to streamline your coding process: https://lnkd.in/eR_VG8hn #JavaDevelopment #Java #JakartaEE #DevMode

7

I'm a little stuck in the book 📚 . Somehow I can't really get into the "Using External Support" chapter.  How do you integrate external people and companies into your own software development organization? Basically, it is perfectly valid to get external help if you  - do not have the knowledge yourself  - need additional capacity  - need some flexibility in the organization - External people are cheaper (for whatever reason). Then probably near-shore or off-shore. This works both in the short term (with a valid training period) and in the long term. I have seen this work for all roles. Software developers, QA, Ops, designers, UX and product managers (owners). However, I find industry and business model knowledge very important for product people and am less likely to outsource this than other roles. What percentage do you outsource?  - My rule of thumb is 70% internal and up to 30% external. It can go as high as 50-50.  - But I've also had teams where only the product manager was internal and everyone else was external in the sense of body leasing, working to our processes and specifications. What else works? What doesn't work? What should we avoid? 

3

11 komentarzy

Get up and running with Java lambdas confidently - in conceptual, practical and intuitive manner - in 30 minutes! https://lnkd.in/dMda77Jd #development #programminglanguages

1

Your tests are mocking you! Jakub Zalas explored test double, when it's best used, and common pitfalls in his talk at the PHP UK Conference 2024. Watch it here - https://buff.ly/3wfVwys #phpuk24 #php #phpc #phpukconference #codetests

12

It is said that sometimes writing automated tests is an afterthought. Perhaps, it is even more so for User Interface (UI) related works, because if we can test it in our browser where it is more "perceivable", why test it in "headless" mode? It is hard, boring, etc. etc. When writing automated tests is treated like a chore, it makes sense that the activity itself is not enjoyable. That was why I wrote this blog post: if we don't see past the effort, it is hard to see the value. Hopefully, this blog post can spark something in our mind which allows us to have more fun in writing automated tests.

18

It's quite eye-opening to learn that a lot of software development projects hit a snag right at the finish line. Did you know that a whopping 80% of the work actually happens in the last 20% of the project? This crucial stage often doesn't get the attention it deserves. Many development agencies find themselves struggling here because of poor planning and budget issues, which sadly leads to projects being abandoned prematurely. What starts as a 6-9 month journey can unexpectedly stretch into years or, even worse, never get completed.

17

3 komentarze

Guys, if you're finding it tough to use git cli, I recommend you use Lazygit (https://lnkd.in/dxXW_jek). It's a great TUI alternative to just plain git. It also helps us understand how git works even if you are a complete noob. Also, to understand git and the commands and tools it offers, there is this crazy game named [Oh My Git](https://ohmygit.org/), introduced to me by my friend Yash D. that basically helps us understand git from a time traveller's perspective, and it is Amazing! Try it out!

2

1 komentarz

Pair Programming is superior to working alone. But Mob Programming is Pair Programming on steroids. When you Mob, you get the best of Pairing, plus: • No silos • Socializing all-day • No internal meetings • Less exhaustive than pairing • Only shared responsibilities - no heroes • All team members are involved in every decision • Getting loads of done while laughing and celebrating together When you work alone, you get the best work you can do alone. When you work in a Mob, you get the best work the entire team can do.

328

127 komentarzy

Should every #juniordeveloper focus on the number of connections they have on LinkedIn? This was the debate from last nights workshop. What do you think? Is this the networking strategy you are employing? Does it work? Is it worth it? Fyi, there are 2x workshops for #developers on my course. Visit the Crushing Digital website for more details.

29

21 komentarzy

🌟 Webpack Got You Stuck? No Worries! Debugging Like a Boss 🚀 Ever feel like Webpack throws cryptic error messages at you? Fear not, fellow coders! Today (Day 135 of #365DaysOfCode), I levelled up my Webpack skills by tackling debugging and troubleshooting common issues. Now I can: Decode Webpack's Messages: Interpret error and warning messages like a pro, identifying problems quickly. Configuration Confidence: Adjust loader and plugin configurations to resolve issues. I even simulated a build error to practice fixing it firsthand! Problem-Solving Prowess: This experience sharpened my problem-solving skills, equipping me to tackle future build challenges efficiently. Tomorrow's Adventure: Get ready, React! I'm excited to explore integrating TypeScript with Webpack, leveraging my TypeScript knowledge for even more robust and reliable builds. What are your best tips for debugging Webpack builds? Share your experiences in the comments. #Day135 #DailyLearning #Webpack #Debugging #Troubleshooting #React #TypeScript #365DaysOfCode

25

Our final video from codebar Festival is now LIIIIIVE 🎉 Demystifying Documentation with Leo Riviera In this talk from codebar Festival, Leo goes into depth on the importance of documentation, why you need it, who it is for, when you should write it and how to write it. 🎥 ➡️ https://lnkd.in/d-i948h8

2

1 komentarz

Talking within our team about how finding proper abstractions will often (always) make code structure just 'click' I remembered the share-pie story from DDD - and luckily found this https://lnkd.in/dzZfVngd . It is also, what I remember most from the book.

3

2 komentarze

🤓 It's not hard to hire a senior developer You're just not offering them what they want. I posted a survey in a Slack group with devs, asking this question: "Would you as a senior developer be open to change jobs NOW if you can work 100% remotely?" (Btw, many of them are social and will come to the office more often. They just want true flexibility and quality of life. And to be fair, they want to do what they love, which is coding, with the minimum amount of interruptions.) Although the dataset is small, the results are interesting. 💸 38 % are willing to take a lower salary if they can work remotely ❓ 17 % would join a company that has some financial uncertainty if they can work remotely 😑 41 % would take a job with a less exciting role, product and techstack if they can work remotely This is an incredible opportunity to hire some seriously great engineers. Especially if you: — Can't pay the highest salaries — Don't build spaceships or AI agents — Are located in a small town or rural area Are there tradeoffs and challenges with (some) remote team members? Of course. But I just can't understand why more companies are not willing to take some risk here. You might regret this when the market turns upwards again. 🕺🏻

105

43 komentarze

#Java is still one of the most popular technologies in the IT world, so it's no wonder that it often becomes the topic of our blog articles. 🔥 Here are some great publications about it: 👉 Java 21 features: A detailed look at the most important changes in the new LTS release – Arkadiusz Rosłoniec: https://bitly.cx/mmqm 👉 Java 17 features: A comparison between versions 8 and 17. What has changed over the years? – Darek Wawer: https://bitly.cx/1qn2 👉 How to code well? With good practices, a great team, and Java code quality tools – Krzysztof Olejnik, Bartosz Świątek: https://bitly.cx/3lH 👉 Advanced Java interview questions: A guide for 2023 – Bartosz Podgórzak, Marcin Gosiewski: https://bitly.cx/h5f 👉 Project Valhalla – Java on the path to better performance – Darek Wawer: https://bitly.cx/nX34w 👉 Clean-architecture Java: How ArchUnit can help your application – Darek Wawer: https://bitly.cx/K1kI

6

1 komentarz