Burk Hufnagel

Thanks for the information.  I had heard about OODA (and John Boyd) a long time ago but had never thought about using it as a way to teach something.  I'm putting together a 4-hour class on TDD and I think your suggestion will help make it a better class.

I believe that teaching something is a great way to learn more about it since I have to understand the *why* behind what I'm recommending. I find that teaching a topic means I have to look at it from multiple points of view. I've also found it helps to remember the issues I had when I was first learning it so that I can address those issues and make it easier for my "students" to succeed with it.

Thanks again,
Burk

Hello,
I'm curious bout your experience writing a Head First book. Did it change the way you think about Android and how to explain things in general?
I'm also wondering if this is a major update from the second edition?

Thanks,
Burk

I suspect it depends on what you mean by proficient.  Given that the book is 900+ pages long, it's going to take some time to go through it -- but you'll probably have a better understanding of Android, and how to write good apps for it, than you would with a different book.  Head First books tend to go deeper into a topic so you'll actually know what you're doing.

Just my two cents
Burk

Thank you! I'm looking forward to reading it.
Special thanks to the authors for their help with my performance issues. I'm still working on it, but your advice has helped me in making headway.

D & D,

Another newbie question -- I'm working on an inherited (from another developer) browser app that has a data entry form that can be used to either create a new request or edit an existing one. It uses the antd library for the various fields and I've been asked to modify the code so that when the user is editing an existing request, the Save button is disabled unless one or more of the fields has been changed.  This makes sense but I'm concerned about keeping track of whether or not anything has changed.  When the user is editing an existing request, I have access to the original data returned by a web service, so I could make use of each field's onChange method and compare it's current value with the original, but I'm hoping there's a better way. Any suggestions?

Thanks,
Burk

I'll definitely look into the testing library and profiler.

In the meantime, I found that several of the components had another class declared in the same file, but outside of the component, and it was the same code copy/pasted into those files. So, I created a separate file for it and imported it instead. The class constructors are still being called multiple times, but it did reduce the overall codebase size and means I only have to make changes in one place if there's an error in that code.

The other thing I found is that even though the constructors are called multiple times, the class methods that call external web services are only being called once. It's like it creates an instance and starts to use it, but keeps creating copies that remain unused, until the component gets the data it needs so it can be rendered. Does that make any sense to you?

Thanks in advance,
Burk

I'm relatively new to React and the application that's having issues, but I can tell you that App does not declare any components within itself. This is a web app using the antd library so App sets up the basic layout of the pate. It imports several classes like Header, Footer, Sider, and Content then declares an onCollapse method to open or close the Sider (which contains a menu) and ends with the return method that sets up the layout for the page.

Looking at the console log, I can see that when I select some of the pages from the menu the constructor only runs once, but on others, it runs multiple times. I'll check the code to see if the pages where it runs multiple times contain other class definitions.

Thanks for the info - it may help solve this mystery and improve the app's performance,
Burk

Hello David and Dawn,
I'm working on an inherited React application that's behaving oddly, and I'm hoping you can help me with it. When the app runs, it seems to call the constructor for each object three times. I'm new to React, so I did some research and found references to StrictMode -- and sure enough, the index.tsx file had the same code I see in your book:
ReactDOM.render(  <React.StrictMode>    <App />  </React.StrictMode>,  document.getElementById('root') )
So I removed the React.StrictMode tag around the <App/> tag, and rebuilt the app, but it still calls constructors three times. I searched the code and don't see any other places where React.StrictMode is being used so I'm wondering if there's anything else that might cause this kind of behavior?

Thanks for any help you can offer on this,
Burk

Mark,
This looks like a very interesting book. Is there anything in it that is specifically for programmers or software architects, or addresses a problem we tend to have?

Thanks,
Burk

Mark,
Welcome to the Ranch. It's a sunny place for shady people... or something like that.  

Himanshu Ahuja wrote:Yes and if there are any tools available to do so

There are plenty of tools out there, like SpotBugs (successor to FindBugs) and SonarQube (with plugins), and most IDE's will support setting up coding standards and showing you when your code doesn't follow them.

corey haines wrote:Hi!

I think a lot of that depends on the constraints and people's familiarity with TDD. Most people that I ran into came to a coderetreat with the expectation that it was "a chance to practice or learn TDD," so they at least tried. Personally I always emphasized that a coderetreat is a great time to try new things, since the goal isn't to finish the implementation, nor even to get anywhere at all. If a single test is written, but it is a great test, then that session should be considered successful.

-Corey

Thank you for the response. I was hoping to leverage your experience and get a feel for TDD adoption around the globe. Based on what I've seen in Atlanta, GA, USA, it seems that TDD still isn't common (less than 50% use it) and that many senior developers don't want to try it because... fill in the blank -- while younger developers at least seem open to the idea, give it a shot and mostly find it valuable.

Liutauras Vilda wrote:I guess quite usual answer is when current implementation no longer works with new requirements. So really there is no quality evolution with an existing functionality. Which is of course sad.

But if the code no longer meets the requirements that means the new version behaves differently than the original code, so the change doesn't qualify as a refactoring. Right?

Liutauras Vilda wrote:Burk, have a cow for quality question. Let's wait and see what author has to say about that.

It's been a while since I last visited. I had to look up the significance of receiving a cow. Thank you. I appreciate it.

Campbell Ritchie wrote:Or whether they believe that getting the app working implies they have written good code

I've seen that a lot with experienced developers, but when I ask them how often they refactor their code, the smiles go away...