Friday, February 27, 2015

CSS - div #foo vs div#foo - How a space cost me an hour worth of frustration

I start "coding" again and quickly ran into the "pulling my hair out" moment on why I cannot troubleshoot the simplest of things. By "coding," I mean working on stylesheets. Yes, I have not even reached the real code stuff (yet I suppose I do have much fewer frustrations there because the syntax is more strict there).

So, I am working on a layout with a site div that contains many sub-divs which may also have additional sub-divs. I was able to get styles up quickly and easily, then I wanted to add a width to the highest parent of divs and for some reason it would not work. I tried all sorts of combinations of switching ids, spell checking, and checking other divs. It works for all the divs except the parent one.

Here is basically my layout:

 

 

   

 

 




And my style sheet:
div #foo { width: 800px; border: 1px solid black; }


No matter what I did, nothing happened, yet if I changed #foo to #top or any other id, I would have a banner. Then finally, I removed food and made it separate from the other divs completely. Suddenly, I had no borders at all except for left, content, and right.

This made me realize that having a space meant the sub-object of the previous object. In other words, CSS is looking for an object named foo inside of a div. Because foo is the parent div, there is no parent div thus CSS does not find a foo instead a div. This is why all the other divs changed accordingly because they were all within a div, foo (whether it was named or not).

So the proper way that I should have coded this was to remove the space between div and #foo, thus making it div#foo. All my problems went away! FINALLY! Nothing like this to remind how foolishly amateurish I can be.

Even #foo would work, but I thought I would be cool by being a little more specific. Even in hindsight, I should have known this because I have used similar practice with classes. Although, I admit that I actually didn't know this difference even though I have developed websites for several years. Usually, I have a placeholder div so I never ran into this problem but not realizing that was what kept all my designs working. Of course, I decided today to not do that because I just felt like making the design insignificantly more efficient.

As for searching on google, this was not easy to find because "css style not working" brings up a lot of results. And "css style working on all objects except parent" did not return what I was looking for. Defining this issue is still not simple even though I have figured out the problem. Perhaps, this problem is too easy to even be mentioned. Hopefully (or perhaps not), I am not the only person to run into this problem and this would help someone in the future........ perhaps my future self!

Wednesday, February 25, 2015

Buggish: Candy Crush 787 - Unable to click after candy combo with frog on conveyor

There seems to be a bug when you trigger a stripe and wrapper combination with a frog in the blast path while on the conveyor belt. At least, that is my best guess as I have used that combination while the frog was not on the conveyor without any problems. The bug is that I can no longer click on any candies. I can still click on the exit game.

This bug is kind of annoying because I was about to beat the level. This level is one of those that requires quite some luck to beat.

Saturday, February 21, 2015

Outlook 2013 vs Outlook 2010 (First Impression)

The biggest issue I have with 2013 is that it does not automatically pop-up the replies or forwards. I often have to copy information from one email to another, so not being able to quickly switch from one email to another is quite bothersome without changing the default settings. So, I do not like this new feature unless there was an easy way to tab back to my previously viewed emails.

There seems to be more bugs with 2013 than 2010. 2013 crashes more often, lags more often, and other odd behavior. This occurs even when there is no stress on the system. For example, I would just do a typical email check and Outlook could just crash completely or it hangs for several seconds.

For some reason when I am not on VPN, I cannot view my regular inbox. I have no looked into saving/caching emails onto my local system but why would this default change? I rarely have issues with disk space on the local system. Group mailbox seem slower to refresh when I switch between my mailbox with a group mailbox even if I was just in the other mailbox.

Still unable to assign the organizer to a meeting. This is quite annoying as I still cannot find a way to change this after opening a new meeting. I still have to go to the mailbox before creating a new meeting. Even if it is static or constant for a meeting, couldn't there be at least a query box to ask which mailbox I want to use? I would still like the ability to change the organizer to a meeting because some coworkers can never remember to use the group mailbox. 

2013 seem to be bulkier with no new advantages to my daily use so far. The ribbon style does not bother me as much as other people make it out to be. I actually find it easier to edit emails and files with the new ribbon. People's biggest complaint is that they cannot find the features. Yes, it was kind of annoying but it only takes an extra minute or two. They should learn to scan/read more accurately. But given some of the other work that I've seen them produce, I doubt they will ever really learn. 

Overall, Outlook 2013 is functional and usable. I prefer 2010 primarily because it seemed more stable. I only use the most basic of features like compose email, setup meetings, and group mailbox.

Friday, February 13, 2015

TED: A Kinder, Gentler Philosophy of (Career) Success

Why do we care so much about our career and about our material goods? Alain de Botton gives an amusing discussion on how we feel and the reality of why we feel that way. Even with current social advancements, new social problems arise. Where do we go from here?

Reference

http://www.ted.com/talks/alain_de_botton_a_kinder_gentler_philosophy_of_success?language=en#t-18995

Monday, February 9, 2015

I am not a fan of agile / scrum (Software Methodology)

I am not pro-agile, but also not anti-agile. I did just enjoy reading a post by Giles Bowkett on "Why Scrum Should Basically Just Die In A Fire." I think agile methods (including Scrum) can work, but time morphs any processes and agile is no different. Giles presents a lightly-humored touch on how Scrum can go wrong.

For me the biggest issue with agile (at least today) is its inability to weed out poor-performing members. Even weeding out bad-performing members is pretty difficult. The second biggest issue with agile is the ability to game the company system. Another big issue that most sites do not point out is that agile is not good for high risk solutions, especially solutions that may determine real life and death risks like medical solutions or an airplane.

There are other issues that agile also do not manage well is regression test. It requires that it to be automated which is fine, but how would it regression test features that take up real physical time like scheduled jobs that are triggered daily or even weekly. Agile also loses performance when dealing with multiple components or multiple environments, where the project essentially becomes traditional methods to coordinate all the different pieces.

Poor-Performing Teams

My biggest problem with poor-performing members is that we have the misconception that those members are dumb. In reality they are just not good at their role, but are smarter than people credit them to be. So this allows a lot of freedom for people to game the system or start politicking.

The easiest excuse is that agile is new, so they still need to work out the kinks. Blame the other group, blame the requirements, blame coding, blame testing. Everyone just points fingers at everyone else. Sadly, these poor-performing teams come out looking better because they are more prepared to blame others while the good teams were working how to fix the issues.

Even if you can isolate the team, identify the individual is even more difficult. There is less information as there is less focus on documentation (if there is an documentation at all). Is the problem with the scrum master not leading properly or the developer not coding properly or the tester not testing sufficiently? Or the scrum master does not have proper support or the requirements are consistently poor or test cases ill-defined? Finding the high-value and low-value members is like a game of mastermind.


High Risk Solutions

I find it odd that I have not come across any sites, posts, or forums (even anti-agile fanatics) mention that agile is not advisable for solutions that have high risks if something does fail. I surely do not want to be on an airplane that went through an agile process... unless maybe if it were on its one millionth iteration and the last 500,000 iterations had no deaths. Or use the laser eye surgery. With my luck, I will probably be that one test case that no one anticipated.

I am also sure that financial companies would not want to risk millions of dollars due to a flaw in the system. I doubt explaining that they didn't provide the proper requirements would make financial companies feel any better. Telling them that the next iteration would correct the problem would not be much consolation. 

Or an online bank losing your life-savings. An individual losing $100 of life-savings will likely be just as angry as another person with $1,000,000 of life-savings. Sure there is insurance for that too but who really wants to go through that experience.

Sure some solutions do not carry such risks like Candy Crush or Farmville (there have been extremes with some video gamers that could probably prove that wrong too). The problem is defining where that line is like a cloud solution that promises 99.99% uptime. Is the risk worth all the customers possibly switching to your competitor?


Documentation

How many people do you know that the value to agile methods is "comprehensive" documentation in its core value: working software over comprehensive documentation? How many of those people even know what that mean? Most people hear "no documentation is needed" (at least the people I know). Not sure how many times I had to point out that we still need some documentation after hearing that they are not supposed to provide documentation anymore because they went agile.

There is definitely something wrong if that value even has to be stated. What company would not love to drop documentation as part of the process if the software just worked? Writing documentation takes up time, and to our corporate world, time is money. I mean they will drop testing if that would save them money too. Besides time and money, I think traditional methods can also drop comprehensive documentation so making it a value of agile is kind of redundant. 

Comprehensive documentation came out of technical writers wanting to keep their job and managers wanting to make people as replaceable as possible which means that the documentation also needs to be continuously updated (mostly the latter which coincidentally didn't get complaints from technical writers). If it is faster to read code to learn what it does than it is too read documentation, the documentation is too comprehensive. I have personally read some old corporate documentation that went into such details as even providing illustrations on single-clicking versus double-clicking or how to move the mouse or how to insert a disk (although the younger generation probably would need that step today).

But my main issue with agile is that people seem to take this to mean "no" documentation. Although it is not stated that way in the manifesto, many people perceive it that way. Developers don't want to document, managers don't want people to waste time documenting, so it appears like a win for everyone. 

That is until 6 months later and the whole development team has changed. New updates are needed on the old code which no one knows about. No documentation, so more time is spent figuring it out. Code is eventually updated and passes the end-user acceptance test. Deploy the change then realize an old process has changed which broke something else. Maybe the change was a comma instead of a semi-colon which passed regression test but fails for the client. The point is more time was spent than was necessary. Management is going to put this as a lesson learned or retrospective, then will require more documentation. 10 years later and we are all going to be back with the issue of comprehensive documentation for agile and traditional methods (or whatever new method name it will be in the future).

I haven't even touched on audit which is already a nightmare with traditional methods. Surprisingly I have not had to experience audit with agile project (yet), but I would guess that it would be just as difficult as traditional in its best case. More likely it would be more painful due to lack of documentation which is a majority of the problems I face in traditional methods. But I supposed it could be easier just to tell the auditor that it just does not exist than trying to hunt down the document, then let someone else worry about what process need to be put into place to "correct" the audit problem.

Solution Complexity

Assuming a great and awesome agile team, the agile method will slowly become similar to traditional methods as the solution grows in complexity and scale large enough to partner with other groups. Having to coordinate times, priorities, and many values to traditional methods, agile cannot avoid certain decision gates needed for multiple team coordination. Agile can work purely in the requirements through development phase, but once it reaches integration another branch of code is required. Then the company will also need another set of testers and developers to fix issues because the agile teams are to be working on the next iterations. If the same team is used, then most of the agile iterations are pretty moot.

Assuming another team is available to support code that is being prepared for production, processes need to be available to merge code to any code that is still open. Further regression test is required. And this is probably the easiest and most regular process.

How will the group manage if there is a production issue that needs to be corrected while in the middle of an iteration? What if it happens to be in the middle of an iteration and in the middle of integration? Is there a separate team? Does integration stop to work on production issue? Now there are at least 3 branches of code being developed. That is only if the code is for one group.

Working with multiple groups, departments, partners, etc., there is bound to scenario where there is not enough resources. In traditional world, all the requirements are coordinated. For agile, this may be more difficult because iterations now have dead-lines which is almost counter to its values. One of the groups may keep its agile schedule, but the others have to coordinate accordingly to their dependencies. Working with other partners may even mean coordinating different flavors of agile methods.

And this is becoming more and more commonplace, as companies have software solutions for billing, accounting, finances, manufacturing, sales, and other departments. Then you want to interact with other companies.

Conclusion

I think agile is basically the same as traditional but just from a different view angle. I think traditional has always been trying to go agile, and many companies probably have made it work. Most of those methods are probably more agile than traditional compared to the corporate world. I think some would argue that it was more or less lean processes like six sigma.

I spent most of my career with small to medium sized companies which basically are traditional methods in a very fast paced world which forced us to be very agile-like. So when I learned agile, most of it was already very familiar except without all the fancy terms and ceremonies. The learning curve was actually harder when I worked with a corporation sized company where the bureaucracy was so daunting.

So, I feel that agile is either the leanest process of traditional method or a traditional method that goes through many prototyping that just never gets refactored. In the smallest of worlds, developers at the very beginning is the truest form of agile where we our own client, product, end-user, developer, and tester. Came up with an idea, tried to program, test, check with initial idea, come up with new idea, develop, test, accept the result, repeat if not acceptable, then becomes final product when accepted.

Saturday, February 7, 2015

Life: Exercise 20150207

After a week, I have returned back to the same weight as last week. I gained quite a bit of weight eating all the food from Superbowl weekend... too much pizza, wings, chips, and so many other not so healthy foods. I gained about 4-5 pounds within 2-3 days. Took another 2-3 days to lose that.

I still exercised everyday except Sunday. This week was kind of sluggish. I did mostly walking on Monday and Thursday. It was harder to run long distance. I found doing amateur-level intervals (2 minute walking and 2 minute jog/run) helpful in getting me out of the sluggish feeling.

Weeks ago, I was only able to do 5mph jogs, now I am able to reach 7mph. Not only that, my heart rate does not reach as high as before. My ankle issue seems to have gone away but I have been avoiding extended jogs. I've tried a couple times and now it seems that my right calf gets tight or tired. Running does not seem to bother me at all even at longer distance and longer periods of time.

It has been about a month since I joined the gym. I have been going almost every day. I think I have missed a total of 5-6 days. I do mostly walk/jog for 1 hour. I do mix up my running exercises between extending my long distance running, just plain walking, and intervals (trying to increase my run pace). When the gym is quieter, I will do some weights after an hour on the treadmill. Overall, I've lost about 7 pounds.