Logo

Who is talking?



Archive

parking lots

over 2 years ago | Rohan Kini: Confuscionomo


(Video should load up in a bit)

Cycle of Change : Video Coverage on CNN IBN

Kiruba has a more detailed write up on his blog of what the plans are.
Currently there are two sets of bikers - one in Chennai and the other in Bangalore who are looking to accomplish something small in 4 weeks. We are supposed to document the whole process on tape so that CNN can show this as a part of their citizen journalist show.

In Chennai - these guys are looking to organize a bike to work day and maybe have a bike race in January
in Bangalore - we are looking to introduce bike parking stands in the city.

Dunno what the status quo is with the various groups. But been so freaking busy that I have had no time to do anything for this at all. Very sad. Would have very much liked to have contribute more than what I currently am.

over 2 years ago | Riju Kansal: Riju's Thoughts Captured...

1. Get an overview of software testing
http://en.wikipedia.org/wiki/Software_testing
http://www.softwareqatest.com/http://www.testingfaqs.org/

2. Learn simple tools


3. Discussion Forums for Testers
  • http://www.sqaforums.com

4. Certification

ActivMobs on Economic Times

over 2 years ago | Rohan Kini: Confuscionomo

ActivMobs, featured on Economic Times.

Nice writeup

Testing on High: Bottom-up versus Top-down Test-driven Development

over 2 years ago | Ryan Kinderman: kinderman.net :

I recently talked to a number of Rails developers about their general approach to testing some new functionality they're about to code. I asked these developers if they found it to be more useful to start testing from the bottom-up or top-down. I suggested to them that, since Rails uses the MVC pattern, it's easy to think of the view, or user interface, as the "top", and the model as the "bottom". Surprisingly, nearly every developer that I asked this question of answered that they prefer to start from the bottom, or model, and test upwards. Nearly every one! I expected that I'd get a much more mixed response than I have. In fact, I think that the correct place to start testing is precisely at the highest level possible, to reduce the risk of building software based on incorrect assumptions of how best to solve a user requirement.

Bottom-up Testing

Bottom-up testing implies bottom-up design in TDD. In bottom-up design, a developer would probably consider the high-level objectives and break them up into manageable components that interact with each other to provide the desired functionality. The developer thinks about how each component will be used by its client components, and tests accordingly.

The problem with the bottom-up approach is that it's difficult to really know how a component needs to be used by its clients until the clients are implemented. To consider how the clients will be implemented, the developer must also think about how those clients will be used by their clients. This thought process continues until we reach the summit of our mighty design! Hopefully, when the developer is done pondering, they can write a suite of tests for a component which directly solves the needs of its client components. In my experience, however, this is rarely the case. What really happens is that the lower-level components tend either to do too much, too little, or the right amount in a way that is awkward or complicated to make use of.

The advantage of bottom-up testing is that, since we're starting with the most basic, fundamental components, we guarantee that we'll have some working software fairly quickly. However, since the software being written may not be closely associated with the high-level user requirements, it may not produce results that are necessarily valuable to the user. A simple client could quickly be written which demonstrates how the components work to the user, but that's besides the point unless the application being developed is a simple application. In such a case, the bottom-level of components are probably close enough to the top-level ones that there is little risk involved in choosing either the bottom-up or top-down approach.

Unless you're writing a small application, the code is probably going to have to support unforeseen use cases. When this comes as a result of ungrounded assumptions about the software that's already been written, this can mean a lot of rework. I can tell you from experience, once you realize that your lower-level components don't fit the bill for the higher levels in the system, it can be quite a chore to go back and fix, remove, or replace all of that unnecessary or incorrect code.

Top-down Testing

Top-down testing implies top-down design in TDD. Following the top-down approach, the developer will pick the highest level of the system to be tested; that is to say, the part of the system that has the closest correlation to the user requirements. This approach is sometimes referred to as Behavior Driven Development. Whatever it's called, the point is that you test the most critical parts of the application first.

Since software is often written for human users, the most critical parts usually involve the front-end as it relates to the value being provided by the system being developed. When testing from the top-down, the effort is the inverse of bottom-up testing: Instead of spending a lot of time thinking about how the components to be developed will be used by other components to be developed, the focus is on how the user needs to interact with the system. Testing involves proving that the system supports the required usability. For an application with a graphical front-end, this might involve testing for a minimal version of that front-end.

The disadvantage of top-down testing is that you can end up with a lot of stubbed or mocked code that you then have to go back and implement. This means it might take longer before you have software that actually does something besides pass tests. However, there are ways that you can minimize this sort of recursive development problem.

One way to minimize the time between starting development of a feature and demonstrating functionality that is valuable to the user is to focus on a thin slice of the overall architectural pie of the application. For example, there may be a number of views that need to be implemented before the system provides some major piece of functionality. However, the developer can focus on one view at a time, or one part of the view. That way, the number of components that need to be implemented before the system does something useful is small; ideally, one component in each architectural layer that I need build out, and often times only a part of the overall functionality of each component.

Another way to minimize the amount of time before the system does something useful is to code a small bit of functionality without worrying about breaking the problem up into classes until you have some tested, working code to analyze. You can then use established methods for refactoring to bring the code to an acceptable level of quality.

The advantage of top-down testing is that you write functionality that solves the most critical functionality first. This generally means starting development at a high level. When the system eventually does something besides pass tests, what it does will provide value to its users. Additionally, because development starts at a high level, the code that is written is based on the current understanding of the problem, and not on assumptions. This guarantees that the tests and code that are written are not superfluous.

Conclusion

The challenge with top-down testing is that you must be highly disciplined to ensure that the code you write is being refactored and is properly evolving into a cohesive domain model for the application. This is compared with bottom-up testing, where you start with the domain model and build your system around it. Either way, you're going to be refactoring code. The difference is in where the time in refactoring is spent. In my experience, when doing bottom-up testing, more time is spent correcting incorrect assumptions about how the domain model will be used than on actually improving code that already works to solve the user requirements. In order to avoid making assumptions about the code being written, it must be written at the level that is closest to providing actual value to the end-user. In so doing, the developer focuses on continuous refinement of code that already provides value, as opposed to speculative design and development.

Bicycle parking

over 2 years ago | Rohan Kini: Confuscionomo


Design a bicycle parking stand - NOW  (Poster designed by Chaitanya)


The bigger picture. We at BOTS have been wanting to slowly start improving the bicycle amenities in the city.  Bicycle lanes, bicycle parking lots, safety awareness for bikers, simple products that can make your life easier etc etc. Some are in the pipe line and some have been gathering dust, due to lack of time, not interest.

Recently CNN IBN got in touch with us and asked us to take up one activity related to biking and take it thru in a span of 4 weeks for some programme of theirs. We were extremely hesitant as we were swamped with work and all these short term thingies really dont work out. But then there was another group in Bangalore which was enthu about this too. Formerly called A.I.R, now renamed Go Cycle. We met up a few times and decided that parking lots for cycles was something that could be addressed.

So here goes. We are going to introduce bicycle parking lots in 3 places in the city and see how it holds and then introduce them all over the city. Hopefully. So stuff to do
- identify locations for the parking lots
- design the stand
- figure out funding
- execute it

One place that we identified was outside Lalbagh. Its a shame to see 100s of folks who ride/drive up till lal bagh. Walk inside and then drive back. Seems utterly pointless. Atleast 10 of these could be converted to biking till there and then biking back home. There were a few other locations.

- design the stand. We are asking some person to design it. But it would be really nice if interested people could take a stab at it and see if they could come up with something interesting. I want to design some really nice posters on this and see if we can have some kind of bicycle parking lot design contest (lack of time is a problem here). Should be a lot of fun.

- funding and execution. Seems far away !

Overall pretty exciting. Parking is an issue right now.
Only problem is time.

Bug: composite_primary_keys and belongs_to with :class_name option

over 2 years ago | Ryan Kinderman: kinderman.net :

For those of you using the composite_primary_keys gem as of version 0.9.0, you may encounter an issue if you try to do something like:

class Reading < ActiveRecord::Base
  belongs_to :reader, :class_name => "User"
end

When a User is loaded up from the database via the reader association, the CPK modification to ActiveRecord::Reflection::AssociationReflection#primary\_key\_name incorrectly returns "user_id" as the primary key name. If you encounter this issue, I've submitted a patch against revision 124 that can be obtained here.

Hopefully this will get fixed in the next release. More hopefully, I won't need to care by then.

Root Cause

over 2 years ago | Rohan Kini: Confuscionomo



Root Cause

AppleScript: Reverse screen colors on a Mac and keep a black background in Terminal

over 2 years ago | Ryan Kinderman: kinderman.net :

Sometimes, it's such a hassle to get up and turn on a light when I'm in the middle of coding. Other times, I don't have control over the lighting, like in a dim pub or cafe. In dim lighting, it's a strain on my eyes to be looking at black text on a white background. I've tried dimming the brightness, but that decreases the contrast, which is also a strain on my eyes. Then, I discovered Control+Option+Command+8, which is a keyboard shortcut to the "Reverse black and white" Universal Access feature. Contrary to it's name, it does more than reverse black and white, it reverses all of the colors on the screen. This, however, is acceptable and requires only a slight mental adjustment for me. Now I use a nice black-on-white color scheme in TextMate for coding, and when I'm in dim lighting, I simply reverse the colors and it's white-on-black, still full-contrast. I'm happy, except for one thing.

I often have a number of Terminal windows open when I'm working, and I open and close them frequently. Although I'm happy with a black-on-white color scheme for TextMate, I can't tolerate anything but white-on-black for my normal Terminal windows. So, what happens when I throw the screen colors in reverse is that all of my lovely white-on-black Terminal windows go to black-on-white. Unacceptable! Thus began my first foray into AppleScript.

After referencing here, here, and here, along with the Terminal "dictionary", I came up with this:

tell application "System Events"
  tell application processes
    key code 28 using {command down, option down, control down}
  end tell
end tell

tell application "Terminal"
  if default settings is equal to settings set "White on Black" then
    set settingsSet to "Black on White"
  else if default settings is equal to settings set "Black on White" then
    set settingsSet to "White on Black"
  end if
  set default settings to settings set settingsSet
  repeat with w in every window
    set current settings of w to settings set settingsSet
  end repeat
end tell

This script first invokes the Control+Option+Command+8 keyboard shortcut to reverse the screen colors. It then toggles the default "settings set" for Terminal to one of two pre-defined sets I've created: "White on Black" and "Black on White". Hopefully the names are self-explanatory. Then, the script iterates over all currently-open Terminal windows and changes their current "settings set" to whatever the new default is.

Pretty simple. I named the script "Reverse Screen Colors" and dropped it in /Users/[user account]/Library/Scripts. I invoke it via the keyboard with QuickSilver.

Winning the DARPA Grand Challenge

over 2 years ago | Rohan Kini: Confuscionomo

Rajesh had pointed me to this a LONG time back, but a bout of sickness and joblessness made me check it out today.

Amazing stuff. Inspirational, to do what I dunno. But good eSthuff.

Trek University

over 2 years ago | Rohan Kini: Confuscionomo


Trek University

[info]nikhile and I had a chance to attend Trek University. Till date whatever we know about bikes was self learned - by experimenting, making mistakes and reading from books and the internet, which is a kinda slow process.

For the first time we met guys, technical guys from Trek who have been doing this for over 30 years, who really loved their bikes and it showed ! The time that we spent with them was brilliant. They knew what they were speaking about and even better, understood why they were doing it. And they rode bikes ( sarcasm, but important :) ).

Kinda makes me understand why the age old tradition of a Gurukul was so awesome. If you are really interested in something you might not be able to learn it by just attending a session or two. You got to live the path and a fast track way would be to stay and work with a person who is substantially better than you in that field.

The little time that we spent with these guys gave us an insight into the way Trek works. Apparently these guys go around the world taking dealers through what Trek stands for, what their bikes are capable of and the kind of research thats happening in this field.

Awesome stuff.

worth of a tree ?

over 2 years ago | Rohan Kini: Confuscionomo



A Friend recently gave this to me. Not sure how the numbers are arrived at.
But the gist was pretty important :)

Ubuntu Webcam story

over 2 years ago | Karthik Ramachandra : Concrete Abstractions

There was this webcam... (now you can guess the story ;-)

It refused to wake up on windows vista, it indeed slept well on xp too,
..(now comes the boring part) -
It just started playing on ubuntu. Fullstop. End of story.

All i had to do was this:

mplayer tv:// -tv driver=v4l:width=640:height=480:device=/dev/video0

Way to go!