Still in Hong Kong, or maybe on the way back. Hard to know with time zones. Read Software Engineering in Practice today.
Tag: software development
-
Redgate Lives DevOps
At Redgate, we release a lot of changes to our products. In fact, this is the “About Redgate” slide I’ve been using in talks related to the company.
If you look in the lower right, you’ll see product releases from last year (2017). We have 30-ish products, so that’s roughly 38 releases per product. Not every product releases at this cadence, but a lot of them release every week. SLQ Monitor, for example, releases every Wednesday.
Of course, there’s the inevitable release-a-bug-and-need-to-fix-it-so-a-second-release this week, but those don’t happen too often. I’ve been tracking releases this year, and not too many were corrected in the same week, but it does happen.
Some people say that’s the problem with DevOps, but I think it’s the advantage. I guarantee that most software releases include bugs. If you release once a quarter, are you ready to re-release in a couple days to fix something? Or do customers live with issues for a quarter? The advantage of DevOps is we can fix things quickly, in addition to adding new features quickly.
Redgate does some amazing development work and I’m proud of the ladies and gentleman that write the code.
I still complain, and there’s room for improvement, but they do a great job and I try to remember to thank them and complement their work when I do see them.
-
The Master of the Schema
“The database … should be the master of the schema”.
It’s not often I see an application developer talk about the importance of the database, or at least that the database (and data) are very important to the success of the application, but in this case, that’s what I saw. The quote is from this blog, which talks about the problems of the code first approach to building an application. It’s from a Java development company, though it’s their jooQ product blog that actually generates Java code from the database, so they get the need to pay some attention to the database.
The thrust of the article is that using an ORM is fine, but this isn’t necessarily the best way to design your datastore if you need a relational system. There will be mistakes made in naming objects, in structuring them and ensuring indexes exist and more. The longer you go with generated database code from some code-first type system, the more issues you might have later as you try to modify both the application and database, especially the database, since you can’t drop it and recreate it.
If we could drop the tables and rebuild them, life would be great. Maybe we should keep copies of data on the clients, and just reload the necessary data after a deployment… It would make my life easier as a database professional, but I suspect this isn’t the best way to ensure data quality and consistency (not to mention completeness).
I agree that if you’re building an application, you should go database first. At least start with some basic structures and learn to modify them. The practice you get modifying code, with scripts not GUIs, will be invaluable later to both developers and DBAs/admins. You’ll start getting practice and understand what it means to deploy scripts to your database. After all, making schema changes with scripts in your development database is the first “practice” you get for deployment. If you can’t get the scripts to work here, how would you have any confidence they’ll work in production?
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and Libsyn.
-
Better Comments
I assume most of your comment your code.
Well, you probably comment code most of the time.
I’d bet your comments have quite a bit of detail.
And you do this completely inconsistently.
That’s what I’d think, or maybe just what I want. Even the best developers I know will not consistently comment code. You can drift through any project on Github and see this. Those projects on GitHub might even be better documented because people know they are public. In most corporate environments I have worked in, I’ll find that when people get busy, or distracted, or even when they’re experimenting to find a solution, and they don’t write detailed comments. Usually only when someone fixes a bug, with a solution found quickly, do I get a really useful comment.
There are all sorts of ways that people think about commenting their code. I ran across a post from Annette Allen about adding comments. She noted that she has headers in her stored procedures and other comments. However, after a few months, she wasn’t sure that the comments actually helped her. I’ve had that same feeling at times when looking back at comments, both mine and others.
Do you have a method for choosing the words you use to comment code? Jeff Atwood says to comment on why you did something, not what. I’ve seen that before, especially with version control commit comments. We often can look at code to determine what it does, and if you use a VCS extensively, then you can always see the changes that were made between versions. The comments typically give me some rationale for the work I did. Over time, I find that if I think about how I’d explain my reasoning to myself in the future, I come up with a good comment.
You might feel differently, and if so, please let me know. Perhaps there are some good ideas you have about choosing comments, and perhaps you have examples. Some might include a bug or Jira number, which I like, but others may hate. These could be comments inline in code or those you use when comimtting to a VCS.
Share some thoughts today, and if you have any entries for the best code comment, drop them here.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and Libsyn.
