Monday, October 17, 2016
Monday, February 22, 2016
JSP templatesThis was a really useful Stack Overflow answer on how to do templates in JSP.
- Tell them how to do it, but let them be at the keyboard doing it.
- Occasionally, sit with other developers while they write code.
- Set goals to improve on your strengths, not just your weaknesses.
Friday, February 12, 2016
I hope vue.js gets some corporate backing. I hope it works out. I don't know if I would develop an enterprise app using it just yet.
Tuesday, January 26, 2016
A not-so-recent project I worked on convinced me that well meaning assumptions can cost us frustration and time. I was tasked with fixing a bug where duplicate records were showing up in a search tool for certain financial data. The more I tried to understand what the code was doing (specifically a SQL join on an arcane AS400 database), the more confused I felt.
Finally, I realized that the original developer had assumed that certain columns were meant for JOIN conditions, when in fact that assumption was utterly wrong. The data relationships were much looser than originally thought, and the data simply could not be displayed in the old way anymore. To fix the bug, I had to redesign the report with progressive disclosure at each level.
The original developer had trusted some (wrong) intuition, and what some accountants had probably told him. I had trusted that the original application SQL was written with a correct concept of the data model.
We all have blind spots. I've since learned not to trust that the original design was even correct (it was good enough to get by on, but it confused and frustrated people often).
(The original query had joined on "line item numbers", but a check line item isn't the same as a document line item--they are only related by document, not line number; checks could be written for multiple documents, and documents could be handled by multiple checks)...
Anyway, just watch out for assumptions. You have to make them and live with them, but just be aware of them and list them, before you forget you made them. Keep working notes as you do your job. They'll get better over time.
Scribbled notes: podcasts I like, learning as a developer, the advantage of blogging ordinary things.
The idea is that we should share un-refined lessons we are learning as IT workers. The basic idea is that you should share things you learn, without fear, because it helps everyone (I can learn by expressing, you can learn from me--or I hope so). I'll see how it goes for me. Maybe I won't do it much. But I'll try it out.
By the way, Developer Tea is a great podcast. I listen to podcasts on my 30+ minute commute. Go check out some of the episode titles and see if you like the gist of Developer Tea. It's short--episodes range from 5 to 30 minutes, but are never too long (I stopped listening to the 2 hour "this week in tech" a long time ago. Sorry, too much fluff, too much time).
If you know any wiki pages with a good list of podcasts (current, updated), let me know in the comments.
(I used Player FM on Android to listen to my podcasts; I thought Podcast Addict was fairly good too).
It's difficult to learn on the job. How do we shift our and others's perceptions to enable learning?
- Don't be a closet learner. You may get opportunities to do new things. You will have more conversations, which helps you and others.
- Don't share what you are learning right away. If you fail, it looks bad. Show successes and value, not failures.
- Focus on learning in low stakes situations. Especially on the job.
- Early in projects.
- 1 or 2 new technologies within your current stack, not a new stack all at once.
- Spend time with someone who already knows more than you.
- Don't be needy, exhaust their energy.
- Gives you things you can't manufacture on your own.
- They can know you and your mind and learning style.
Let me know if this turns you off to reading my blog (all 4 or 5 of you who read this). Or if it inspires you.
Anyway. That's it for now.
Tuesday, August 25, 2015
Friday, July 24, 2015
"But because they are hard to navigate, hide options by default, don't support hierarchies, and only enable selection not editing, dropdowns shouldn't be the first UI control you reach for. In today's software designs, they often are."
He suggests finding the right alternative in each case, such as steppers, radio groups, sliders, switches, 2-way sliders, button groups, date pickers, and so forth.