Hi everyone,
I got an hardware question. Im planning on getting a personal home server. I want to use it as a small gitlab server, continues integration, and the like for personal projects.
It has to be power efficient otherwise my dad will start crying.
I want it to be relatively cheap and running linux.
Ive got no clue what the best thing todo is. Should I get a prebuild one or build one myself.
For prebuild ones, what brands should I look at?
For a custom built what hardware do you recommend me?

When integrating our system with a 3rd party company to use their billing system, we had a Hangouts chat so we could ask things about their documentation, API, etc...

Me: *explain the problem and how I tried to solve it without success, and proceed to ask 3 things*

*2h of silence*

3rd.p: Good Morning
Me: Good Morning
*another 2h of silence*

Me: ...and?
*1h of silence*

3rd.p: *answer randomly one of the questions*
Me: ok, and the other two questions?

*silence until the next day*

Me: ???
3rd.p: *answer one question and says that the other will never happen*
Me: but... I've just sent a request to your backend and it happened!!!

*2h of silence*

3rd.p: No, you are reading this wrong, we didn't respond that
Me: This is the endpoint i'm calling and the request's payload, send this to your backend.

*silence until the next day*

(and this continues to almost 2 months to complete the integration that should not need more than 1 week)

Extremely frustrated with the release process and versioning system at my current company. Don't know if this is same everywhere or the half ass release managers can't think of a better way here.

Basically for any client raised issue that can't wait for next release are built as a hotfix. However hotfixes are never bundled togather or shiped to other clients. This is causing a vicious chain, two clients raise two separate issues on same version. Instead of fixing them as single hotfix (however minor the issues) we create two hotfix versions for each with only their issue. A week later same clients come back with the issue the other raised. Once again instead of bundling what is now effectively same code we build hotfixes on top of the clients respective branches. We now have two branches to maintain with same codebase. No matter how serious issue, the hotfix is never made generally available and always created on client's specific hotfix version.

Now that was an example for only two clients, in reality we have released five patch versions of a product in last 2 years. Each product version contains about a dozen artifacts (webapps, thick clients, etc) with its own version. Each product version being shipped to various clients. Clients being big banks never take a patch of product even if it fixes their issues and continues requesting hotfix. We continue building hotfixes on client branch and creat ever increasing tech debt. There is never a chance to clean up or new development. Just keep doing hotfix after hotfix of same things.

To top if all off, old branches are still in svn while new in git. Old branches still compile with ant new with maven. Old still build with java 5,6,7 while current with 8. Old still build from old jenkins serve pipelines while new has different build server. Old branches had hardcoded integration db details which no longer exists so if tou forget to change before releasing it doesn't work.

Please tell me this is not normal and that there are better ways to do this? Apologies I think I rambled on for too long 😅

Still as a scholar who has had his intership I decided that I was finally confident enough in my ability to apply for a small part-time programming job. I had an internship at a cool exhausting place with tons of expertise and I've proven myselve over there. So now I wanted a job on the side. Nothing special, just something that would make a little money with programming instead of washing dishes at the restaurant.

So I started at this small internet based startup (2 or 3 progammers) as a backend-oriented programmer. The working hours were amazingly compatible with my school schedule.

The lead dev also sounded like a smart guy. He had worked as a backend guy for years and had code running on verry critical public infrastructure that if it were to fail we'd be evacuated from our homes.

As a first asignment I got an isolated task to make an importer for some kind of file format that needed integration. So I asked for access to the code. I didn't get it since they were going to re-do the entire backend based on the code I wrote. I just needed to parse the file in a usable object structure. So I found out that the file format was horrible and made a quite nice set of objects that were nice. At the end of the first week or so I asked if I could get access to the code again, so I could integrate it. Answer was no. The lead dev would do that. I could however get access to my private repository.

Next week a new intern was taken to build a multiplatform responsive app. Only downside was that all the stuff he had ever done was php based websites. It wasn't going anywhere anytime soon, but I figured that that was where internships were for. So I ended up helping him a lot and taught him some concepts of OOP and S.O.L.I.D. and the occasional 30 minute rants of IndexOutOfRangeException, ArgumentException and such.

So one day he asked me how to parse a json string and retrieve a specific field out of it.
I gave him something like the following to start with:
"
JObject json;
if(!JObject.TryParse(jsonString, out json))
{
//handle error
}
string value;
if(!json.tryget("foo", out value).../// code continues
"

but then the main dev stepped in and proposed the following since it wouldn't crash on an API change:
"
dynamic json = new JObject(jsonString);
string value = json.myJsonValue;
"

After me trying to explain to him that this was a bad choise for about 15 minutes because of all kinds of reasons I just gave up. I was verry mad that this young boy was forced to use bad programming pracises while he was clearly still learning. I know I shouldn't pick up certain practises. But that boy didn't.

Almost everytime the main dev was at the office I had such a mindboggling experience.

After that I got a new assignment.
I had to write another xml file format parser.
Of course I couldn't have any access to our current code because... it was unnecesary. We were going to use my code as a total replacement for the backend again.
And for some reason classes generated from XSD weren't clear enough so after carefull research I literally wrapped xsd generated code in equivalent classes.

At that moment, I realized I made some code that was totally useless since it wasn't compatible with any form of their API or any of the other backend code. (I haven't seen their API. I didn't have access to the source.) And since I could've just pushed them generated XSD's that would've produced thesame datastructure I felt like I was a cheat. I also didn't like that I wasn't allowed to install even the most basic tooling. (git client or, Ide refactoring plugins, spelling checker etc...)

Now I was also told that I couldn't discuss issues with the new guy anymore since it was a waste of my valuable time, and they were afraid that I taught him wrong concepts.

This was the time that my first paycheck came in so I quitted my job.
I haven't seen any of the features that I've worked on. :)

@Work: Every new project, we need a new server for CI/CD...
Whiteboard + bets on how many weeks it will take to get some servers provided.

Design in Motion: Real-Time Rendering's Impact on Architecture

Architecture, a discipline that once relied heavily on blueprints, models, and lengthy render times, has undergone a revolutionary transformation in recent years. The advent of real-time rendering technology has fundamentally altered the way architects visualize, present, and interact with their designs. This paradigm shift has not only enhanced the creative process but has also empowered architects to make more informed decisions and create immersive experiences for clients and stakeholders.

Real-time rendering, a technological marvel that harnesses the power of high-performance graphics hardware and advanced software algorithms, allows architects to generate photorealistic visualizations of their designs in a matter of milliseconds. Gone are the days of waiting hours or even days for a single rendering to complete. This acceleration in rendering time has not only expedited the design process but has also encouraged architects to explore multiple design iterations rapidly.

One of the most significant impacts of real-time rendering on architecture is the ability to visualize a design in various lighting conditions and environmental settings. Architects can now instantly switch between daytime and nighttime lighting scenarios, experiment with different materials, and observe how their designs respond to different seasons or weather conditions. This level of dynamic visualization offers insights into how a building's appearance and functionality evolve throughout the day, contributing to more holistic and thoughtful design solutions.

Moreover, real-time rendering has transformed client presentations. Architectural concepts can now be communicated with unprecedented clarity and realism. Clients can virtually walk through spaces, observing intricate details, exploring different angles, and even experiencing the play of light and shadow in real-time. This immersive experience fosters a deeper understanding of the design intent, enabling clients to provide more targeted feedback and make informed decisions.

The impact of real-time rendering on collaboration within architectural teams cannot be overstated. Traditionally, architects and designers would need to wait for a rendering to complete before discussing design changes or improvements. With real-time rendering, team members can make adjustments on the fly, observing the immediate effects of their decisions. This seamless collaboration not only enhances efficiency but also encourages interdisciplinary collaboration as architects, engineers, and other stakeholders can work together in real-time to refine designs.

The integration of virtual reality (VR) and augmented reality (AR) into the architectural workflow is another transformative aspect of real-time rendering. Architects can now create VR environments that allow clients to step inside their designs and explore every nook and cranny. This not only enhances client engagement but also enables architects to identify potential design flaws or spatial issues that might not be apparent in 2D drawings. AR, on the other hand, overlays digital information onto the physical world, facilitating on-site decision-making and construction supervision.

Real-time rendering's impact extends beyond the design phase. It has proven to be a valuable tool for public engagement and community involvement in architectural projects. By creating virtual walkthroughs of proposed structures, architects can offer the public an opportunity to experience the design before construction begins. This transparency fosters a sense of ownership and allows for constructive feedback, contributing to the development of designs that resonate with the community's needs and aspirations.

The environmental implications of real-time rendering are also noteworthy. The ability to visualize designs in various environmental contexts contributes to more sustainable architecture. Architects can assess how natural light interacts with interior spaces, optimizing energy efficiency and reducing the need for artificial lighting during the day.

In conclusion, real-time rendering has ushered in a new era of architectural design, propelling the industry into a realm of dynamic visualization, immersive experiences, and enhanced collaboration. The ability to witness designs in motion, explore different lighting conditions, and interact with virtual environments has redefined how architects approach their craft. From facilitating client presentations to fostering sustainable design solutions, real-time rendering's impact on architecture is profound and multifaceted. As the technology continues to evolve, architects have an unprecedented opportunity to push the boundaries of creativity, efficiency, and sustainability in the built environment.