Lucian Maly

Many thanks for the ebook. I am truly honoured to receive it and looking forward to read it! Special thanks go to Chris for coming over and answer our (silly) questions :-)

Junilu Lacar wrote:I think the best way to approach this is to capture all potential improvements (use a keyword in the comments of your code that the entire team will agree on and use, e.g. #TODO:) during the "initial" development sprints. Scrum master/PM should then turn it into lower priority tickets as you go and then have at least one more "refactoring" sprint(s) only for these tickets.
Ouch. You just described what many practitioners would call an anti-pattern. Refactoring is best done as soon as you get tests to pass, which should be done frequently and incrementally. This (what you described) is more like a way to ensure that refactoring gets pushed to "later when we have more time," which of course you only do when, as you say, you have already been bitten (usually by a P1 in production).

This kind of misunderstanding of what refactoring is is what I was afraid would result from the recommendation to wait until you've written all the code to refactor. In my experience, that "big bang refactoring in the end" approach just gets you in more trouble than it supposedly saves you; it's usually much more costly than  incremental and in-the-moment refactoring.

In my opinion, larger scale refactoring efforts that require their own "tickets" (ugh) should be reserved for legacy code that you have to maintain. Certainly, spending some time refactoring and fencing in legacy code with characterization tests is a good and prudent practice.

This way, you will not go too far and start attacking "theoretical" problems, but identify and fix components that have actually bitten you along the way.
Sure, there's a chance that inexperienced folks get too carried away and get too "theoretical" about what should be refactored and how it should be done but in general, if you keep with the Four Rules of Simple Design, you really only need Rename, Extract, and Compose Method most of the time. Almost all other refactoring techniques are just one or a combination of these three applied to a specific set of conditions. I have found Rename, Extract, and Compose Method to be sufficient for 80% of the refactoring that I need to do "in the moment."

Can you please provide a legitimate source for your statement that this is an anti-pattern? I worked in some fast-paced agile environments and immediate refactoring was always perceived as a "waste of the development time" and "not adding any features while there are deadlines to meet". It would be nice to hear what is Christian Clausen's opinion of this...

Theoretically speaking you can go on refactoring indefinitely because there is NEVER a perfect code. I think the best way to approach this is to capture all potential improvements (use a keyword in the comments of your code that the entire team will agree on and use, e.g. #TODO:) during the "initial" development sprints. Scrum master/PM should then turn it into lower priority tickets as you go and then have at least one more "refactoring" sprint(s) only for these tickets. This way, you will not go too far and start attacking "theoretical" problems, but identify and fix components that have actually bitten you along the way.

Interesting points Chris! I am also working as a consultant (but the truth is i'm mostly infrastructure focused) and use more Python and Golang. But i understand where you are going with this reasoning...

What you said will definitely motivate me to think more about the size of my methods, thanks.

Hi Chris,

Do you plan in your book to go into a detail of different refactoring approaches and their pros/cons? I see those chapters are not yet ready, but i would like to see some examples of e.g. red X green refactor method, refactoring by abstraction, composing technique, simplifying methods, moving features between objects and preparatory refactoring etc.?

I am particularly interested in relation to tests. Refactoring MAY cause old tests to fail, so in addition there might be some effort to create new tests. What amount of time should be invested as part of a refactoring effort of both in-depth and regression testing? To ensure that the functionality of the solution was not affected in any way... I hope you get my point.

We just released eBook: Running Kubernetes on your Raspberry Pi homelab that you might be interested in!

Hi Christian,

I have two questions -

[1]
By quickly scanning some chapters, all the coding examples presented in your book are written in TypeScript. Any particular reason for choosing that language?

[2]
You made a statement that a method should not contain more than five lines (excluding opening and closing brackets) and the title of your book reflects that. Why do you think five lines are enough for a single method?

Thanks and have a great day!

Welcome to CodeRanch, Christian Clausen. Enjoy your stay!

Sorry, what is the question?

@Tim Holloway

I'm actually primarily using Pi3 because of the power consumption reasons and i bought cheap heatsinks on eBay to prevent it from overheating (although it is not overclocked) and to significantly increase lifespan/longevity in case they would discontinue it.

I will let the author answer that, but it seems like Helm is going to be covered in Chapter 10, Week 2. We shouldn't ask too many questions, otherwise he would not be able to finish it :-D

Specifications
SoC: Broadcom BCM2711B0 quad-core A72 (ARMv8-A) 64-bit @ 1.5GHz
GPU: Broadcom VideoCore VI @ 500MHz
RAM: 1GB, 2GB, or 4GB LPDDR4–3200 SDRAM (4GB as reviewed)
Networking: Gigabit Ethernet, 2.4GHz and 5GHz 802.11b/g/n/ac Wi-Fi
Bluetooth: Bluetooth 5.0, Bluetooth Low Energy (BLE)
Storage: MicroSD
GPIO: 40-pin GPIO header, populated
Ports: 2x micro-HDMI 2.0, 3.5mm analogue audio-video jack, 2x USB 2.0, 2x USB 3.0, Ethernet, Camera Serial Interface (CSI), Display Serial Interface (DSI)
Dimensions: 88mm x 58mm x 19.5mm, 46g

Raspberry Pi 3 Model B+ Thermal Benchmark:


Raspberry Pi 4 Model B Thermal Benchmark:


Power Draw Benchmark:


Thermal Throttling Benchmark:


Linpack Benchmark:


Memory Throughput Benchmark:


File Compression Benchmark:


GIMP Image Editing Benchmark:


SpeedoMeter 2 Browser Benchmark:


OpenArena gaming benchmark:


Gpiozero benchmark:


Ethernet throughput benchmark:


WiFi throughput benchmark:


USB throughput benchmark:


MicroSD storage benchmark:

Senior Infrastructure Consultant in North Sydney, Australia

Job summary:

The Red Hat Consulting team is looking for an experienced Senior Infrastructure Consultant to join us. In this role, you will join an organization that is at the forefront of helping customers develop hybrid cloud solutions and guide digital transformation as they grow in existing and new markets. You’ll represent Red Hat and our culture in your customer engagements and at technical forums, speaking to audiences varying from customer architects, engineers, and developers to community user groups about Red Hat technologies, solutions, and services.
Your customer engagements will require you to do practical work with, and design solutions for, our industry-leading enterprise open source software including Red Hat OpenShift Container Platform, Red Hat Ansible Automation Platform, Red Hat Satellite, and Red Hat Enterprise Linux (RHEL). As a Senior Infrastructure Consultant you will be expected to become an expert in one or two of these technologies and to develop sufficient knowledge of others to architect solutions involving multiple Red Hat products and associated technologies. You may work with our customers on your own as the Red Hat subject matter expert and you may work as part of a Red Hat team, providing technical leadership to the team and to the customer. You need to be proficient in building good customer relationships because you will often play a key role in managing customer expectations and developing further consulting opportunities for Red Hat. Successful applicants must reside in a country where Red Hat is registered to do business.

Primary job responsibilities:
- Become a respected and trusted Red Hat subject matter expert, focusing on our customer's business outcomes and addressing their architectural, technical, development, and strategic IT requirements - Architect, design, implement, and integrate Red Hat container and infrastructure technologies, primarily Red Hat OpenShift Container Platform, Red Hat Ansible Automation Platform, Red Hat Satellite, and Red Hat Enterprise Linux (RHEL) - Promote the adoption of automation techniques and DevOps practices to improve the infrastructure and software life cycle including infrastructure and application uptime, availability, and time-to-market - Participate in mentoring and knowledge transfer to your customers - Contribute your knowledge and experience back into the wider Red Hat community for help other teams and customers - Collaborate with the sales and presales teams as a subject matter expert in Red Hat solutions to position and guide great customer outcomes

Required skills:
- Background in architecting and designing complex infrastructure solutions in a rapidly evolving technology domain - 10+ years experience working with enterprise customers on a range of infrastructure deployment projects in an on-site capacity - 5+ years of experience designing container based solutions using kubernetes - 10+ years practical technical experience in UNIX and Linux systems, preferably in Red Hat products including Red Hat Enterprise Linux (RHEL) and Red Hat Satellite - Expert technical capabilities in automation tools such as Ansible, Puppet and Chef - Experience with virtualisation technologies such as Red Hat Virtualisation, KVM, VMware and Hyper-V - Experience in modern methodologies such as agile development and DevOps, and associated capabilities like automation, orchestration, and configuration management - Ability to conduct workshops and to create and present effective presentations - Ability to act as a technical mentor to consultants and customer staff, providing valuable, timely, and accurate technical mentoring - Ability to travel up to 40% between major cities in Australia and New Zealand - Experience with DevOps practices and tooling such as Maven, Jenkins, and Bamboo - Experience in public cloud technologies including Amazon Web Services (AWS), Microsoft Azure, and Google Compute Engine (GCE) - Experience managing a small team in a technical leadership capacity

Send me a personal message, if you are interested in pursuing it.

Hi,

I wanted to know your opinion on non-vanilla—but still Kubernetes under the hood—alternatives like Red Hat OpenShift/Origin, Heptio, Rancher, Platform9 etc. From your experience, where do you see fit of these products in the future?

Best regards,

@paul nisset

I'm not sure what you did, but It is impossible to create multi-node cluster with minikube. Minikube simply uses underlying VMware/VirtualBox/KVM/HyperV... to spin up one-node Kubernetes virtual machine (VM requires ~5GB of RAM) and configures the kubectl to use that VM. That's all.

If you want to use something similar (one-node playground), but without too much overhead, you may want to try combination of classic Docker and Kind. It essentially uses Docker images to simulate Kubernetes nodes.

For something more robust, but in the cloud - i would recommend using Amazon Elastic Kubernetes Service (Amazon EKS), which is a fully managed Kubernetes service. The simplest way to create/delete these K8s clusters is with CLI eksctl.

Hit me up if you have more questions.