Posters or Billboards containing only Facebook and Twitter icons, without their URL or handle. #Failhttp://t.co/UyATEgjH3 hours ago
@Kurt_Haeusler Fair enough. I guess what matters to me is the intention of the person more than the speaker. But I can see a bias kicking in 6 hours ago
How good are you at limiting red time? .i.e. apply limiting WIP (Work-In-Progress) concept to Programming and Product Development.
What is Red Time?
During Test Driven Development and Refactoring, time taken to fix compilation errors and/or failing tests.
While Programming, time taken to get the logic right for a sub-set of the problem.
While Deploying, downtime experienced by users
While Integrating, time spent fixing broken builds
While Planning and Designing, time spent before the user can use the first mini-version of the product
And so on…
Basically time spent outside the safe, manageable state.
Let it be planning, programming or deploying, a growing group of practitioners have learned how to effectively reduce red time.
For example, there are many:
Refactoring Strategies which can help you reduce your red time by keeping you in a state where you can take really safe steps to ensure the tests are always running.
Zero-Downtime Deployment which helps you deploy new versions of the product without your customers experiencing any downtime.
Continuous Deployment which helps you get a change made to code straight to your customers as efficiently as possible
Lean Start-up techniques which helps validate business hypothesis in a safe, rapid and lean manner.
Over the years we’ve realized that it always helps to have simple tools to visualize your red time. Visualization helps you understand what’s happening better. And that helps in proactively finding ways to minimize red time.
On many applications I’ve worked on, Authentication is a big pain.
Usually its an usability hazard. (No one likes to authenticate themselves over and over again)
Since its a cross-cutting concern and every application has some special logic for authentication, we spend way too much time hand crafting the best strategy to implement and test it to make sure our application is secure.
When you have multiple applications and you want to implement single-sign-on, the pain just exponentially amplifies.
On high scalability apps, Authentication (session validation) can be expensive from performance point of view
In the search of simplicity, I’m wondering if there are alternative techniques to implement authentication on certain types of applications.
One thought comes to my mind, which I’m curious to try. I’ll start with a very specific example and then expand it to other applications.
While building web applications in the category of social networking or eLearning or some other category, where retrieving data from the app is not very critical from a security point of view:
Even if you have a stale session cookie, GET request works fine without requesting you to authenticate. Only when you POST, authentication kicks in.
This approach will certainly not work for a banking application, where reads also have to be very secure. But for many application reads don’t need to be very secure. Also most applications have relative very small number of POST requests, which means very few times the user would be nudged to authenticate themselves. Most RESTful frameworks can have this built in.
Can this approach be used for rich-client apps instead of just web-apps? I think so.
We plan to keep a max cap of 100 participants for this conference.
As you might be aware SDTConf is a free conference and we use the concept of position papers as the price for admission. This helps us ensure the quality of the participants is really high. You can add your position papers for the conference on our wiki. Making the position papers public helps other participants gauge in advance what they can expect from the conference.
Last but not the least, since this is a community run, non-profit event, we really on sponsorship in kind to make this event possible. Here is a list of items that you or your company can sponsor to support this conference.
P.S: Please blog about this conference and/or send an email to your friends and colleagues. Word of mouth is the only way we market this event.
You’ve heard about limiting WIP (Work-In-Progress) but how good are you at limiting red time? Red time is when you have compilation errors and/or failing tests. A growing group of practitioners have learned how to effectively reduce red time while test-driving and refactoring code. To understand how to limit red time, it helps to visualize it.
In this talk, I demonstrated various strategies to limit your time in Red. We also analyzed a live programming sessions using graphs that clearly visualize red time. Participants learned what development processes help or hurt our ability to limit red time and gained an appreciation for the visual cues that can help make you a better developers and fellow member of the Limited Red Society.
