text:
I learned something interesting about LINQ today, and I'm surprised that it took me this long to run into this.
Do you think this test would pass?
public class Account
public int AccountId { get; set; }
public string Status { get; set; }
public class Test
public void Deferred_execution_test()
var accountIds = new[] {1, 2, 3};
list = accountIds.Select(accountId => new Account {AccountId = accountId});
foreach (var account in list)
account.Status = "Active";
foreach (var account in list)
Assert.IsTrue(account.Status == "Active");
It actually fails.
I'm sure when you've been debugging code you've at some point seem something like this:
The key is the "Expanding the Results View will enumerate the IEnumerable". This means that it hasn't yet executed the code in the
Select() clause. So every time you access the IEnumerable<T>, it's going to execute the
Select() statement, which means that it will new up new Account objects every time.
This test will pass:
public class Account
public int AccountId { get; set; }
public string Status { get; set; }
public class Test
public void Deferred_execution_test()
var accountIds = new[] {1, 2, 3};
list = accountIds.Select(accountId => new Account {AccountId = accountId}).ToList();
foreach (var account in list)
account.Status = "Active";
foreach (var account in list)
Assert.IsTrue(account.Status == "Active");
All I did was add
.ToList() to the end of the statement after the
Select(). This executes the
Select() statements and stores and actual
List<T> in the "list" variable instead of a
WhereSelectArrayIterator (which has deferred execution).
Just something to keep in mind if you're using
Select() to new up some objects.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
In a previous post, I talked about data analysis and how you can use data to help you plan and estimate better. Now let's talk about what specific things we can track and what we should do with it.
Types of metrics
I have to separate metrics into two categories – metrics that stay within the team and metrics that I share with others. The tricky thing about data is that data has no value on its own, the value is in the interpretation of the data. When I share data and metrics with people outside the team, I want to make sure that either I'm presenting the interpretation of the data or I'm presenting the data in a way that others will be able to interpret it correctly.
I can't emphasize this enough. The worst thing that can happen is that you present raw data and people interpret it the wrong way. Also, if you present data without interpretation, people on your team will think about how others will interpret the data and change their behavior so that things will be interpreted in a way that makes them look good.
Interpretation, not just data
Management likes metrics. They realize that we can learn a lot from data and that it can give them an idea of how a project is going. They might not say it, but what they really want isn't the data, it's the interpretation (based on the data) that has real value for them.
A great example of this is burndown charts. Here's a burndown chart from a project I was on:
You can take two very different interpretations from this burndown:
1) The project is ahead of schedule and everything is OK
2) The project is at risk because we aren't that far ahead of schedule and things have been going surprisingly smooth, and as soon as we run into any hiccups, we might not be done in time
The problem is that I presented data without interpretation and allowed it be interpreted by management. I find that managers can tend to be overly optimistic with their interpretation of data (especially when it comes to timelines). But there are things that I knew about the project that either weren't reflected on the burndown or weren't very clear:
- We were only about 20 hours ahead of schedule, which for this 2 person team equated to about 2 days.
- The timeline on this project was somewhat optimistic, with the assumption that we would try to control scope increases as much as possible, but on past projects we had run into unavoidable scope increases. This project hadn't had any of those hiccups yet, but the fact that that hadn't happened was unexpected.
As you can guess, management went with interpretation #1, while I felt the truth was interpretation #2. The problem was that I didn't understand how they would interpret the data and I didn't present it correctly.
How would I do this differently? Well, I'll get more into burndowns in a later post. But I would include my interpretation along with the burndown, even if it's something as simple as a red/yellow/green indicator to let them know how I feel about the project, risks/problems we might be having, or even just a conversation about how I feel about things.
Internal metrics
Internal metrics are things that I'm going to track to help me estimate and plan for future iterations, but I'm not necessarily going to publish this information for anyone to see (or maybe I just share it with the team, but not outside the team).
As far as internal metrics, what kind of stuff do I track? Well, it depends on the team and the situation, but here are some things:
- Estimates vs. actuals at the feature level (you can do this whether you estimate in hours or story points)
- Points/hours planned for vs. points/hours completed in an iteration
- Points/hours completed in an iteration (velocity)
- How long it takes for a work item to get from the time the business tells us to work on it to the time that it's ready to go to production (cycle time – I say "ready to go to production" because sometimes you have the work completed, but you don't send it to production immediately for various reasons)
- Work that comes into the iteration after the iteration starts
- How much work gets pushed out of the iteration
- Number of hours worked over 40 hours per week
- Percentage of time spent on analysis, development, testing, and everything else
- User happiness (this one obviously going to be backed up with data necessarily, but if the users aren't happy, I don't know that we're succeeding)
You can collect all of this data, but the value is in how you interpret it, of course!
A popular metric is velocity, but I've found that in order to be able to infer anything from the velocity data, I need to collect the data over a long period of time where almost everything in the work environment is consistent. That means that the team members don't change, people don't take long vacations, the team is doing similar kinds of work over that time period, and any number of things that are often very difficult to control (not to mention that the team might try to game the system to make the velocity numbers look good). Also, I don't care about velocity as much as I care about capacity, or how much work we can get done in an iteration.
I've started taking a different approach to calculating capacity. Instead of using velocity (which in my opinion isn't statistically significant enough), I like to take a gut feel estimate of how much I think the team can get done (which can somewhat be based on velocity data). I will also make estimates for other metrics that are easier to calculate, and then when I see that those metrics are off, I will adjust the velocity estimate accordingly.
For example, all of these metrics are easy to calculate and affect velocity and capacity:
- Estimates vs. actuals at the feature level (you can do this whether you estimate in hours or story points)
- Work that comes into the iteration after the iteration starts (excluding even swaps of one feature for another) – for example, this could be bugs, production support, etc.
- Percentage of time spent on analysis, development, testing, and everything else
- Points/hours planned for vs. points/hours completed in an iteration
- Planned vacations, holidays, or other unusual events
If I see that my estimates for these data points are off, then I can adjust them accordingly and also adjust my capacity estimates up or down. Over time, my capacity estimates should get better and better as I learn more, and I'm basing the number off of data points that are easy to collect and aren't affected by so many variables. So in a way, I'm calculating the velocity of the team by backing into it.
Again, I've categorized velocity as an internal metric. Velocity is too raw of a data point to share with management in my opinion, because then you open yourself up to them wondering why one iteration had lower velocity than another and that sort of thing. I'd rather share my capacity numbers (which are interpreted from data by me) with management so that we can plan for the iteration and future iterations. My interpreted capacity estimate is going to be more accurate, and by doing this I have much more control over the message that I'm sending to management about the project.
External metrics
I really don't have anything to list here, because it all depends on what your management wants to see. The key is to ask them to give you the questions they want answered, and then you come up with a way to answer those questions. That might be in the form of a chart, bullet points with red/yellow/green categorization, a conversation, or whatever makes them feel comfortable. Either way, I want to find a way that will help them easily and accurately see the state of the project.
You have to very careful in what you publicize. Many people (and I've done this in the past) will post velocity charts on the wall for everyone to see. Some people might say that this could motivate the team to try and get things done faster. In my opinion, all this is going to do is distract the team from the goal of delivering quality, working software. Now they might try to game the system to produce more velocity, maybe at the expense of writing tests, having design discussions with the team, working with the users to get it right, etc. I would much rather motivate people by showing them how the project they're working on is going to have a huge impact for the business or the user base. When someone comes to me and paints that picture, man, I want to get the project done tomorrow because I see the impact that it's going to have.
Bad metrics
There are certain metrics that I try to avoid, and this includes anything that could potentially influence anyone on the team to change their goals away from what they should be. For example, avoid any metrics that measure and compare individual team members. I don't even want people to know that I'm collecting this information, because they will assume that anything that you are collecting might be getting shared with management or people outside the team. I know that some developers on the team are faster than others, and if these people report to you, then you might want to compare their performance with others. But you have to be very careful about it. The worst thing you can have happen is that team members stop trying to help other people on the team and only focus on getting their work done. This does not create a healthy work environment at all.
Implied metrics
Just because you don't post a chart with numbers doesn't mean that something that you're doing can't be interpreted as implied metrics. I've seen this happen with agile card walls. For example:
- Does your card wall make it easy to compare developers' productivity levels?
- Does your card wall incentivize developers just getting a ticket to QA vs. getting a ticket developed and tested?
Agile card walls offer up lots of raw data that can be interpreted. This is a really good thing and it's the reason that we use them. But you have to careful about how people might interpret would they say. There's nothing wrong with using some sort of method to show who is working on what, but everything that you interpret from what you see on the board should be about how the team is doing, not how individuals are doing. If the board incentivizes people to work as a team, then they're more likely to do that. But if it incentivizes people to work for themselves, then that's what they'll do.
Metrics are tricky!
Collecting metrics is a difficult task, and often you have to walk the line between providing helpful, meaningful interpretations of data and giving people another way to get the wrong impression about the situation. This takes a lot of intuition and understanding of how the people around you think, work, and interpret situations. But if you can collect good metrics, they will start you down the path to predictable delivery.
Read the next post in this series, Burndown charts.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
Let's take a break from our team-based planning talk about talk about you. Good planning starts with you and your ability to accurately track and plan for how you spend your own time. This will in turn help the team plan because you're able to give the team a better idea of what you'll be able to accomplish.
Track everything you do
Let's be honest — tracking time isn't really that much fun. We'll do almost any menial task before we enter our time in a time tracking tool. Let's put aside all of the accounting benefits of tracking your time (which is real money). Your success will be affected by how well you track how you spend your time.
I started tracking my time because I was doing consulting and I wanted to be ready in case someone came to me and questioned how I was spending my time. Then I started to see that I had a lot of meaningful data that I could use for my own benefit. I was able to look back and see how much time I spent on each project, on each work item, and how much time I spent doing development vs. analysis vs. testing vs. production support vs. project management vs. everything else.
You can track this information however you want, but I prefer Excel because I can set it up however I want and it's easy to view, filter and aggregate past data.
(click for a larger, more readable image)
This is really valuable data. If someone comes up to you and asks you how much work you'll be able to get done next iteration, you'll want to know how much time you typically can spend doing various activities. Often times they don't ask you, but there's an assumption of how much time people spend working on tickets. But if they're assuming that you can spend 80% working on tickets but you actually only spend 70%, that's 8 hours over 2 weeks that they think you have that you actually don't have. Not only that, if you can back up your number with actual data, that's a lot harder to argue with.
Invisible time
If you're not tracking your time, you might have a lot of what I call "invisible time". Invisible time is time that you spend doing something, but you aren't tracking it and you don't know where the time went. This is dangerous because you can actually end up having a lot of invisible time.
We all have random things to do that come up and keep us from working on our tasks that we have to do. This could be answering emails, hallway conversations, researching production support issues, or whatever else that might come up. Usually there aren't tickets for these sort of things. I'm not saying that these activities are bad, but I want to know about them so that I can see if it's getting out of hand.
I'm reasonable about this — I don't write down that I spent 5 minutes answering an email — but if I spend 30 minutes or more doing something, I'm going to record that. I might even create a work item for it if that makes sense, because now other people will know that I did it and how much time I spent doing it.
Create tickets
I like to create tickets for everything I do when it makes sense to do so. This helps me cut down on the invisible time by making it visible to everyone. Having a record of work done in a work item tracking tool helps everyone plan better because it makes things visible to the people doing the planning. Maybe you're getting inundated with production support requests and random analysis requests. Having work items for these sorts of things helps people see just how inundated you actually are and shows people what you're spending your time on. However you do it, the point is that we want visibility into where our time goes.
Compare estimates vs. actuals
How accurate are your estimates? Do you have any idea? If you're tracking the time you spend on a work item, you can compare the actual amount of time spent with the estimate that you gave, and this can help you get better at estimating.
Like many people, I've tended to underestimate tasks in the past. This was because when I thought of an estimate, I would typically think about how long it would take for me to get to a point where someone else could test the feature (after I did my testing, of course). But I found that I usually wasn't accounting for time spent fixing bugs that the testers found, or even looking into questions that testers had about things that they thought were bugs that weren't actually bugs. Once I started comparing my estimates, I was able to see what I was missing and start estimating better.
Protect your time
Let's say that the people doing the planning come to me and ask me how much time I can spend working on development tickets in an iteration, and let's say that I say 70%. While this is technically an estimate, in a way I'm making a commitment to them to try and spend at least 70% of my time working on tickets.
So what happens when your schedule starts to fill up with meetings? Maybe these meetings are coming from people outside your team.
My commitment is to my team first, and everyone else second. If that's true, then I need to proactively manage my calendar so that it doesn't get so full with meetings that I can't meet my commitments.
When I've committed to working tickets, I'm going to block off my calendar for the rest of a day if that day gets more than half full with meetings. Those meetings can wait while I finish meeting the commitments I made to the people that are most important to me.
I'm able to be proactive with my calendar because I decided how I needed to spend my time ahead of time. Whether someone else asks to know this information or not, I can still come up with an estimate for myself so that I can try to hit my personal targets. Then next iteration I can adjust my estimates based on how things went in the previous iteration.
Trust me, it's worth it
While this seems tedious and boring, I've found this information to be extremely valuable and it actually doesn't take much effort to do it (especially once you get in the habit). As a professional, I want to have as much information so that I can make the best use of my time.
Read the next post in this series, Metrics.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
If your team has a lot of periods of crunch time and if overtime happens on a somewhat regular basis, it becomes really difficult to know what is normal anymore. Far too often, the crunch time ends up becoming the norm because your good, diligent, dedicated workers will want to step up to the challenge and hit a date without complaining. But since management sees that you hit the date and things seem to go well with minimal complaining, they might think that it's no problem if the same thing happens again. So what do you do now, plan for people to work 40 hour weeks or 50 hour weeks? Or maybe the number of hours worked changes from week to week. This is a good way to kill morale, and it also makes it really difficult to collect any meaningful data that you can use to help with planning.
Another problem happens when people on your team work more than 40 hours but only report 40 hours on their timesheet. Now you're collecting data that is incorrect, which is going to make you underestimate how much you can get done. I realize that most full time employees get paid a salary and don't get paid extra for hours worked above 40, but people need to be honest about how much their working.
This is a tricky situation, because some people like working extra hours. They want to do it because it's fun. But there are other people that feel like they can't do a good enough job by just working normal hours. You're going to have people that feel inadequate, but I like to find those people and let them know that they don't need to sacrifice themselves like that just to fit in. If people feel stressed or that they can't keep up, they're not going to feel good about their work, they'll be tempted to cut corners, and they won't do their best work. I don't want people to come to work and take it easy and not work hard, but I want their experience at work to be a positive thing in their life.
All of this makes data analysis really hard. What do you do with the person who works 60 hours a week for fun? I don't want to tell them that they can't do that (which I can't really do), but it puts you in a tricky spot when they decide that they can't work 60 hour weeks anymore and you've gotten used to (and planned for) that happening. Or maybe someone is frequently underestimating tickets to make themselves not look bad, but then working extra hours to get it done?
The answer is… I don't know. Every situation is different, you're just going to have to figure it out. I'm just pointing out some issues that can come up.
What we can do is try and create a positive work environment. We should try to create a culture of empowerment instead of a culture dominated by top-down command-and-control management. We should try to encourage and reaffirm the people on our team and help them avoid the impostor syndrome. We should try to improve the lives of the people on the team, which will also affect their performance at work in a positive way.
Read the next post in this series, Personal iteration planning.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
In order to get really good at planning, you need to get really good at data analysis. You need to collect all the data that you can and use it to prove your assumptions and accurately plan future work based on past results. The key word in that sentence is accurately – if you come up with a plan that isn't accurate, that's not going to be much better than no plan at all.
Here are some ways that data analysis has bailed me out in the past:
- I was working for a consulting company and we were doing a project with two phases. We started on the first phase, and when that wrapped up, we were going to bid on the second phase. We had estimated the work for both phases, but the project manager wanted to know how accurate the estimates were, so he had all of the developers track and record the actual amount of time they spent on each work item. We found that we were underestimating everything by 20%. If we hadn't realized that we were underestimating, we would've underbid the second phase of the project by 20%. If you do the math, that comes out to a lot of money we could've lost and a lot of extra hours worked.
- On a recent project, we thought we had enough time to get the work done by the deadline, but when we analyzed how long the work would take combined with the expected amount of scope increase that we expected based on past releases, we were able to predict that we weren't going to be able to make the release date with the current scope and team, 5 weeks before the release date (the project was only a 2 month project).
- On the same project, we were actually ahead of schedule at one point, but we could see that the project had very few road bumps compared to past iterations so we were able to explain that while we were ahead of schedule, we still felt that the project was at risk.
- When planning for an iteration, I was able to see that exactly how much time I had been spending on analysis vs. development so that I didn't over-commit to development work when I really was spending more time doing analysis.
Let me give you an example. Have you ever played the game where you have a jar of jellybeans and you have to guess the number of jellybeans in the jar? Pretty hard to do right? (I've never won that game.) What if someone gave you several other jars of jellybeans of different sizes and told you how many jellybeans were in those jars? It would get a lot easier to estimate the number of jellybeans in the first jar, wouldn't it? What made it easier? You based your estimate off of actual data from similar situations.
We like to say that estimates are always wrong. Why are estimates wrong? Because there are too many variables that we don't know enough about in order to make a correct prediction of what will happen. What if we could reduce those variables, either by controlling the environment or learning more about an activity using past data? As you bring more things under your control, you can become much more accurate with your estimates and your delivery cadence can become much more predictable.
Also, most teams estimate development work, but teams don't always estimate analysis and testing work. Why not? Are those disciplines any less important than development? (The answer's no.) Your BAs and testers should give estimates on tickets just like developers do, and those estimates should be used in the planning process.
Let's look at some of the variables that we can control.
Team members
In order to be able to use past data to help predict the future, you need the team to remain the same for a period of time so that you can begin to see the trend. This means that you try to limit changes to the makeup of the team, and you should not have team members that are only partially dedicated to working on the team. If these things are in flux, it's going to be a lot harder to use past data to predict future performance.
Consistent hours
I turned this point into its own post.
Smaller teams
Any planning is easier to do when you have fewer people to plan for. It's shouldn't be any surprise that the most accurate planning I've done is for teams of 1 or 2 people. If you reduce the number of variables (and people are always variable), you can be remarkably more accurate.
Many of you probably have a team that is larger than just two people, but you can still divide a large team into smaller sub-teams. Remember, every time you add a person to a team, you make it a little less efficient. You add one more variable to the system, one more person that needs to be kept in the loop.
Expecting the unexpected
What's harder that planning for the work that you know about? Planning for the work that you don't know about. This could be unexpected production support issues, scope increase, or bugs that come up during the iteration that increase the amount of work needed to complete a feature. However it happens, it happens all the time, and it often happens in relatively predictable amounts. Occasionally you'll have that really bad week where everything comes to a halt because of serious production issues. But over time, you'll begin to see a trend of how much of this kind of stuff happens, and you can plan for it.
Track everything
The more data you track, the more you will learn. This may seem tedious to your team (for whatever reason, there's nothing developers hate more than tracking their time), but it's really important. There's actually a lot it for them. For example, if a developer thinks that they spend 80% of their time doing development each iteration but they actually spend 60%, they're always going to be over-committing. Maybe they consistently underestimate their features (this happens a lot). If they're being held accountable for getting work done, then they should want to estimate accurately.
Knowledge is power, and data analysis can give you the knowledge that you need to become a better planner and estimator. Next time we'll talk about what kinds of things to track and what kinds of things to not track.
Read the next post in this series, Consistency.
The Task Parallel Library is nothing new (it came out with .NET 4), but recently I had to diagnose some slowness in my application and I thought that the TPL might be what I was looking for, so I dove in.
Doing work in multiple threads is nothing new. You've been able to do
new Thread(...).Start() and
ThreadPool.QueueUserWorkItem(...) for some time now. But if you've used either of those methods, you know that it's not simple and it usually feels like more work than it's worth.
This is where the Task Parallel Library is awesome — it makes multi-threading easy. This doesn't mean that it's trivial (you can still have deadlocks, race conditions, etc.), but now you can introduce multithreading into your application with minimal effort.
I'm guessing that many of you have had the same problem that I had. You have a screen which will load up all of the details about an account/customer/order/whatever your system deals with. If you use a relational database (which most of you probably do), this probably means that you go and run a series of SQL queries (using an ORM or not) to load up all of the data that you need on the screen.
In my case, I had several slow SQL queries that had to run (and by slow, I mean ~2 seconds). The queries weren't all that slow, but if you do 20 SQL queries and each one waits until the previous one finishes, you end up with it taking 12 seconds to load all of the data. Not good.
So what I did was to do each call as a
Task and let the framework do it as fast as it can with as many available threads as possible. This is really easy to do, actually, once you learn a few basics.
Here's a sample of what my old code looked like:
dto.Enrollments = EnrollmentRepository.GetEnrollmentsForAccount(accountId);
dto.Usages = UsageRepository.GetUsagesForAccount(accountId);
dto.Invoices = InvoicesRepository.GetInvoicesForAccount(accountId);
return dto;
(Obviously, I'm simplifying the code a bit for the sake of this post, there were about 20 calls in the real code.)
Here's what the code turned into:
var tasks = new List
tasks.Add(Task.Run(() => dto.Enrollments = EnrollmentRepository.GetEnrollmentsForAccount(accountId)));
tasks.Add(Task.Run(() => dto.Usages = UsageRepository.GetUsagesForAccount(accountId)));
tasks.Add(Task.Run(() => dto.Invoices = InvoicesRepository.GetInvoicesForAccount(accountId)));
return dto;
I really only added two things.
Task.Run() tells the framework to do an action on a new thread.
Task.WaitAll() tells the framework that the execution of the code should wait at that point until all tasks are complete.
With this simple change, I was able to take the loading of an account from ~12 seconds down to 2 seconds!
This is not the first time that I've written code that does things on multiple threads. But this is the first time that I did it and it was this easy. This is important because now it's easy enough to make me think about doing things asynchronously more often. In the JavaScript world, doing things asynchronously is the norm (Node.js basically forces you do write asynchronous server code). It feels a little weird at first, but it makes total sense. If I have this fancy computer that has lots of hyper-threaded cores, why wouldn't I take advantage of it? That would be like having an assembly line with 8 workers but then having one person do all the work while the other seven sat around and watched.
How much can I actually do at once?
This got me curious. I know that I have a quad-core machine, and the cores are hyper-threaded so each core can do 2 threads at once. This means that my machine should be able to do 8 things at once. I decided to find out what would actually happen.
This code will queue up 50 tasks. Each task will sleep for 1 second and then tell me when it finished.
public void How_many_things_can_we_do_at_once()
action = i =>
return (() =>
Console.WriteLine("Task {0} finished at {1}.", i, DateTime.Now.ToLongTimeString());
var tasks = new List ();
for (var i = 0; i < 50; i++)
Here's the output of the test:
Task 1 finished at 10:10:52 PM.
Task 2 finished at 10:10:52 PM.
Task 3 finished at 10:10:52 PM.
Task 0 finished at 10:10:52 PM.
Task 4 finished at 10:10:52 PM.
Task 6 finished at 10:10:53 PM.
Task 5 finished at 10:10:53 PM.
Task 7 finished at 10:10:53 PM.
Task 8 finished at 10:10:53 PM.
Task 9 finished at 10:10:53 PM.
Task 10 finished at 10:10:53 PM.
Task 11 finished at 10:10:54 PM.
Task 12 finished at 10:10:54 PM.
Task 13 finished at 10:10:54 PM.
Task 14 finished at 10:10:54 PM.
Task 16 finished at 10:10:54 PM.
Task 15 finished at 10:10:54 PM.
Task 17 finished at 10:10:55 PM.
Task 19 finished at 10:10:55 PM.
Task 18 finished at 10:10:55 PM.
Task 20 finished at 10:10:55 PM.
Task 21 finished at 10:10:55 PM.
Task 22 finished at 10:10:55 PM.
Task 23 finished at 10:10:55 PM.
Task 24 finished at 10:10:56 PM.
Task 25 finished at 10:10:56 PM.
Task 26 finished at 10:10:56 PM.
Task 27 finished at 10:10:56 PM.
Task 28 finished at 10:10:56 PM.
Task 29 finished at 10:10:56 PM.
Task 30 finished at 10:10:56 PM.
Task 32 finished at 10:10:57 PM.
Task 31 finished at 10:10:57 PM.
Task 33 finished at 10:10:57 PM.
Task 34 finished at 10:10:57 PM.
Task 36 finished at 10:10:57 PM.
Task 35 finished at 10:10:57 PM.
Task 37 finished at 10:10:57 PM.
Task 38 finished at 10:10:57 PM.
Task 39 finished at 10:10:58 PM.
Task 40 finished at 10:10:58 PM.
Task 41 finished at 10:10:58 PM.
Task 42 finished at 10:10:58 PM.
Task 43 finished at 10:10:58 PM.
Task 45 finished at 10:10:58 PM.
Task 44 finished at 10:10:58 PM.
Task 46 finished at 10:10:58 PM.
Task 47 finished at 10:10:59 PM.
Task 49 finished at 10:10:59 PM.
Task 48 finished at 10:10:59 PM.
The test completed anywhere from 6-8 tasks per second in this test run. I did other runs where it never got above 6 tasks per second. It all depends on whatever else my machine is trying to do at the same time that is tying up the cores. The good thing is that the framework is taking care of creating the threads, figuring out when a thread can run, disposing of the thread when it's done, and all of that plumbing that I don't have to worry about.
Learn more
I found a really good series of blog posts that covered all kinds of different topics related to parallelism, threads, tasks, async/await, and everything related to it. It's definitely a new way of thinking for me but I'm starting to think of all kinds of ways that parallelism is going to change how I write code.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
Some teams like to estimate in hours, and other teams like to estimate in "story points". Other people simply try to break down all work into small tickets and just count the number of tickets completed. Other people don't estimate at all. Which way is best?
Of course, it always depends on your situation, and people have views and opinions that are all over the place. I'll give you my opinion and try to accurately represent all viewpoints, but this is just my opinion, so feel free to disagree with me.
Estimating in actual time (hours, days, etc.)
- Estimating in hours makes sense to a lot of people, and they're used to doing it.
- If you're on a project and the team understands the application, the business, and the subject matter very well, you might be able to accurately estimate how long something will take (especially if you can break it down into small tickets).
- Works well when you can have the people who are going to do the work do the estimating. (This works best when you can estimate tickets shortly before you're going to work on them so that you know who will be working on them.)
- Estimates can vary from developer to developer. One developer who has been on the team for awhile and works quickly might estimate something at 4 hours, but a slower developer who hasn't been on the team for awhile might estimate 16 hours. Both estimates are correct (for that person). This is OK, but if you don't know who is going to be doing the work and the 16 hour developer inherits the 4 hour estimate, you're going to have a problem.
- Doesn't work well if you don't know enough about the application, the business, or the subject matter, which makes it really hard to come up with an estimate in actual time that has any chance of being accurate.
- If you track velocity over time, it should be relatively consistent in terms of hours of work completed, but this won't show if the team is getting faster (or slower) over time because the team's estimates of a certain type of ticket will decrease over time. If you estimate in story points, a certain type of ticket will always have the same point value and you will see an increase in velocity over time.
Estimating in story points
Story points are arbitrary values that are given to a feature and then all other features are estimated relative to how difficult each task is to the previous tasks that have been assigned a specific story point value. People measure "points" differently depending on who you ask – some people say points are a measure of time/effort and others say that points are a measure of complexity. There's no one right way, which is the point of this post.
One popular method is to use the Fibonacci sequence numbers as the point values that you can use in your estimates (e.g. 1,2,3,5,7,11,13,17,23). This makes it a little easier because you don't have to agonize over whether something should be a 13 or a 14.
- Works really well if you are estimating a project and you don't know much about the application, the business, the technology, or the subject matter. In these cases, estimating in hours is a complete stab in the dark, but it's much easier to compare the effort or complexity of one feature vs. another. (This happens a lot when you work for a consulting company and your company wins a bid for an entire project.)
- People aren't very good at estimating in actual time, but they're much better at estimating the size of a task relative to other tasks that have specified point values.
- You might have one developer who would estimate a task at 4 hours and another developer who estimates the task at 16 hours. But both developers might estimate the task as 2 points because they're measuring the task relative to other tasks.
- Tracking velocity has more meaning. If the team gets faster over time and now a 2 point ticket takes 4 hours instead of 6 hours, you should see an increase in velocity over time, which is good for the team (especially if you're trying to justify doing Agile in an environment that is new to Agile and is wondering if it's worth it).
- It can be awkward to estimate in story points, especially for new people who don't know how the points have been allocated in the past. Other people have a hard time thinking in terms of story points when estimating a ticket in hours might seem easy.
- Team members and management tend to try to convert story points to hours, at which point people start to feel like maybe they should just estimate in hours anyway.
- Since a story point is arbitrary, it can become really easy to game the system. For example, management wants the team to increase velocity. Suddenly what would be a 2 point ticket now gets estimated as 3 points! (I realize that you could game the system if you were using hours as well, but it's a little harder to do with hours since hours aren't an arbitrary measurement.)
- Management at some point is going to ask for an estimate (read: commitment) where you have to specify a date when you need to be done, so you're probably going to have to translate points to hours.
Counting tickets
- Estimating feels like a waste of time and the estimates are often wrong anyway. If the tickets are all small and relatively close in size, the differences in size all average out anyway so we can just count the number of tickets and it will come out close enough. (This, of course, is dependent on being able to break down the work into small tickets of about the same size, which is hard to do on some projects.)
- No more estimation meetings!
- Doesn't work well if you aren't able to break down the work into really small tickets.
An alternative way to count tickets is to have a small number of sizes of tickets (e.g. small/medium/large). This is similar to estimating in story points, but it's less granular. You still count tickets, but each ticket has a point value (for example, small = 1, medium = 2, large = 3).
No estimation
- Works well if you just work the tickets as they come to you and you don't have to do long term planning (e.g. handling production support, ongoing maintenance).
- Works well if a good portion of your work is not known up front and just comes to you when it needs to be done.
- Won't work if you're working on a project where management needs to know when it will be done.
More on story points
I often hear complaints from people that like story points. They say, "Management keeps trying to translate story points to hours!" My response to that is, what's wrong with that? If you're on a story point project, eventually you'll have enough data to show that a 1 point ticket typically takes X hours on average, and so on. Isn't that a good thing? Aren't you better off if you're able to translate story points to hours? Who wouldn't want to have that knowledge?
This doesn't mean that you can't continue to estimate in story points, but remember, the whole point of estimating is ultimately to tell management or the business when you are going to get work done. There is still value in story points (more meaningful velocity charts, easier to estimate in some cases, etc.), but at some point the translation to hours is probably going to be necessary.
Use your brain
I find that people are very passionate about this topic, and the most passionate ones either think that you should always estimate in story points or never estimate in story points. I don't like to use words like "always" or "never" because you can always find a situation where it makes sense to do things a certain way.
This is where you come in. You can read all of the books and blog posts that you want, but ultimately you need to use common sense and find the estimation method that works best for your team. There's no harm is trying something and switching to something else later. The important thing is to do more of what works and less of what doesn't.
Read the next post in this series, Data analysis.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
If you ask people what they think of estimates, they'll probably tell you that "estimates are always wrong". But at the same time, management is taking those "wrong" estimates and treating them as a commitment to get work done by a certain date.
In reality, I think both of those things are true. The problem is that they seem so contradictory to each other, and this is where many teams get into trouble.
Many of you probably feel that estimating is a waste of time. It doesn't make sense that you have to spend time each week estimating tasks when you could be using those hours to get things done.
I would love to live in a world where I didn't ever have to estimate anything and all I would have to worry about is what I'm working on now and maybe what I have to work on next. Some of you might work in that kind of environment (maybe you're in a small shop). But most businesses need to know how much things are going to cost, if Team A can complete a project before a certain date because Team B is going to need the functionality in place, if it's worth it to build custom software or buy something off the shelf, or which consulting company to choose for a project. That's the nature of smart business.
Or think of it this way – if you were going to build an addition on your house, would you not get several estimates from multiple builders and use those estimates as a major factor in who you picked to do the work? You certainly wouldn't pick someone who said, "I do good work, so I'll do the best that I can and then I'll let you know how much it costs in the end."
The fact is that if we want to be professionals, we need to be able to give good estimates, and we need to accept the fact that management is really asking for a commitment when they ask for an estimate. The whole reason that we estimate, regardless of the methods we use to do it, is so that we can tell management or the business when are going to get work done. Fortunately there are some things that we can do to come up with better estimates.
Small tasks
It's much easier to estimate smaller things than larger things. What's easier to estimate – the distance between your house and the one 3 houses down or the distance between New York and Chicago? You probably wouldn't get either exactly right, but the margin of error will probably be less on the smaller distance.
The same is true when we're breaking down a piece of work that we want to estimate. I like to break things down into the smallest unit that makes sense. Now that's a pretty vague statement, but it really does depend on the situation. Ideally I like to break things down into the smallest testable unit that makes sense. That means that the feature provides some amount of value to someone (the business, IT, the dev team, etc.) and it can be tested and moved to production (or ready to go to production). There are always exceptions though – sometimes the smallest testable unit I can get to is still a week of work for 2 people, so then I'll break the development down into smaller pieces (e.g. UI layer, business layer code, write some stored proc that is going to take awhile, set up an environment, etc.). Those technical tickets won't be testable by themselves, but I'll also have an overarching ticket that represents the testable unit (which is made up of the smaller techincal tickets). This at least lets us estimate smaller things so that we can be more accurate and have a better sense of how the work is progressing.
I'm not going to tell you what the maximum size of a ticket should ideally be, because every project is different. I've been on some projects where most tickets are under 4 hours of dev work, and I've been on other projects where the estimates were in days or weeks. The goal is to get the functionality broken down into the smallest chunk that makes sense for you so that you can get the estimate to be as accurate as possible.
Story Points or Hours?
There was enough here for it's own post.
Categorization of work
On our team, we estimate analysis, development, and testing. So what counts as what? How does you categorize time spent by a developer writing automated tests? When a QA person writes a test plan, is that analysis or testing? What about meetings where you're talking about a feature?
You can come up with your own rules of thumb, but here are mine:
- Time spent doing business analysis (this one is obvious)
- Technical design
- Research into how something works, whether this is business-focused or technical
- Time spent by team members in meetings discussing the feature (remember, 5 people in a 1 hour meeting = 5 hours)
- Coding, writing code, thinking about code, talking about the code, etc.
- Writing automated tests (if your QA people are writing end-to-end automated tests without developer involvement, I might categorize time doing that as QA)
- Manual testing
- Test planning
- Writing up bugs for a feature
- Writing end-to-end tests (see my comment in the Development section)
Other stuff (I might want to track the amount of time spent on these things, but not at a feature level)
- Team meetings not related to specific features (retrospectives, standups, iteration planning, other team meetings)
- Project management
How your team categorizes specific things doesn't really matter, what's important is that everyone is consistent and does it the same way so that you can get good data. You might want to check with your management as well because certain activities are capitalizable (like development, technical design, and testing) and others are not (like analysis).
The people doing the work should be the ones doing the estimating
This sounds pretty straightforward, but it's really important. Let's say that you know a lot about your application and you can complete feature X in 4 hours. But someone else who hasn't been on your team as long or maybe isn't as fast as you might take 16 hours. It's not fair for you to give the 4 hour estimate and then hand it over to the person who is going to complete it in 16 hours. Maybe in that case you let the person re-estimate it at 16 hours, but that could throw your planning off. (This is another good thing about story points – when you estimate the size of a feature relative to other features, both developers might give the same estimate even though one will take 4 times the hours to complete it.)
I've been on some projects where we estimated a good portion of the work up front (because we had to bid on the project). That's fine, but we never re-estimated anything. That led to lots of situations where a developer got assigned a ticket that they didn't estimate, and once they had been working the task for as many hours as were estimated and they weren't done, they started freaking out because they felt like they were behind, and this is when the sloppy code practices start happening. This happened because the people doing the work didn't get a chance to give an estimate. If I give an estimate and I don't finish it in time, then that's on me, and I know it, so I don't have any room to complain.
Nothing is more demoralizing than having someone else commit you to an estimate that you don't feel is realistic. This just makes you feel angry, unmotivated, and unempowered. But if I make an estimate, then I'm a lot more likely to want to meet the estimate, even if it turns out that it's going to take longer than I originally predicted.
Anything can be broken down
Any amount of work, no matter how complex, can be broken down into small, manageable tasks. The most complicated project is nothing more than a collection of simple tasks. The trick, of course, is identifying those simple tasks. But that scary project will become a lot less scary as you identify small units of work that need to be done. This exercise will also give you a better idea of all of the things you're going to have to do, and you will be able to make better estimates on the small tasks.
This also applies to more nebulous roles like project management. Project managers are typically really busy and have to juggle numerous things at one time, but like anyone else, all of their work can be broken down, prioritized, tracked, and estimated. This will also free your mind because you have a system for keeping track of your work other than trying to remember everything in your mind (which is exhausting).
When to do the estimating
When the estimation happens depends on your team, your project, and how your team prefers to do it. I have a couple tips though.
Do the estimation as late as possible. It usually helps to have the work for the next iteration estimated so that you can do the capacity planning for the next iteration. You might have to estimate it earlier (so that you can plan out a release or bid on a project), but you might want to re-estimate that work when it gets closer to when you're going to work on it in case the estimates have changed so that you can plan accurately.
Don't have long estimation meetings. Some teams will have these meetings that last several hours long where the entire team goes through tickets and estimates them. I guarantee you that this will become everyone's least favorite part of the week. Sometimes you might want to get everyone's input on certain features, but for most things, you know who is going to do the work, so I would just let that person give their estimate so that you don't have to tie up the whole team in mind-numbing meetings.
Remember the goal
Remember that however you estimate, the purpose is so that we can tell management or the business when are going to get work done. Use your intuition and come up with the best way that your team can estimate in order to meet this goal.
Read the next post in this series, Comparing estimation methods.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
As an iteration manager, it's your responsibility to make sure that everyone on the team has what they need in order to do their job and complete the work assigned to the current iteration. This can be tricky, but I find that it's the fun part of the job.
Get people talking
Once of the biggest hindrances to success is a lack of communication. I'm sure you can think of examples where a lack of communication hurt the team. Maybe a developer reinvented the wheel because he didn't know about the existing way to do it. Maybe your testers had issues testing some functionality because they didn't know how to use the app correctly when a developer could've quickly showed them exactly how to do it. Maybe the users were confused or uncertain about some of the changes that you were making because they had questions that needed answers.
Someone needs to make sure that people are talking. This doesn't mean that you have to do all the talking, you just have to make sure that you get the right people communicating so that everyone is on the same page.
An easy way to do this is to get the team members to sit together. This sounds obvious and many teams have at least part of the team sitting together, but it really helps having the BAs, developers, and QAs in the same area. Yeah, we might have email or instant messaging or phones, but people communicate so much better when their working in the same area. Plus, it increases team camaraderie, which helps communication even more (and it's fun).
Be the unblocker
It's your job to be the unblocker. This doesn't mean that you just remove blockers for people, you also need to be able to see when people might be stuck and help them to get unstuck again. What complicates this is that many people don't want to ask for help. They might think that they should be able to figure it out on their own, or maybe they don't want to inconvenience people.
Whatever the excuse, there are usually some telltale signs that you can spot. Maybe you don't see progress on something that should be moving along, or maybe you hear people sounding frustrated and complaining that they're having trouble with something. This is where your intuition comes in.
Your job is to do whatever you can to allow people to focus on the work that they need to get done, which is what people tend to want to do anyway. But sometimes someone needs to see that there's a problem and get the right people in the room to talk about it.
Sufficient requirements
I've been on projects that have really well defined requirements and many others that didn't, and let me tell you, it makes a huge difference. If your requirements are only 80% complete, then your developers are probably going to get it 80% right. When QA goes to test, they have questions about the requirements just like the developers did, and they either write up bugs or get in arguments with developers about how things should be.
When the requirements are well defined, you don't have as many of these problems. In fact, you probably shouldn't start working on a feature until you've all talked through it and make sure that everyone agrees on the requirements (which include the acceptance criteria).
What counts as "sufficient requirements"? That's up to you. There are some cases where I feel like I need to write part of the code so that I can find all the things that I'm not thinking of. If I do that, at some point I'll have a better understanding of what the requirements should be, and then we can meet about it.
What I don't want are people not knowing how something should work, or people feeling like they need to make assumptions or decisions about how things should work, or people having to wait for requirements clarification. When things are well defined, everything tends to go smoothly because people don't have to worry about not having all of the requirements and they can just work.
Keep things flowing
You can only move as fast as the slowest part of your process. Here's how this often happens: management wants to get things done faster, so they come to you and say, "Let's get more developers!" That's great, but if you don't have someone to write requirements for that developer or help test their work, things aren't going to move any faster (or maybe they will at the expense of quality).
If even you aren't in that situation, it's virtually impossible to always have perfect balance of analysts, developers, and testers, especially on smaller teams. What do you do if you have 1 analyst, 3 developers, and 2 testers, but suddenly you really need 2.4 testers? The only way to get 0.4 of a tester is to have someone else on the team that is not in tester role help out with testing. This is where it's extremely valuable to have people that can do several different roles well so that you can eliminate bottlenecks in the process and keep things flowing.
This especially applies to developers, because often times the bottlenecks happen when developers get work done faster that QA can test it (and many teams have a shortage of testers anyway). I like to encourage developers to learn how to do other tasks, like analysis and testing. This can help eliminate bottlenecks, and it makes developers better contributors in general. In some smaller teams, the developer is also the analyst and the tester and needs to know how to do these jobs.
Finding the bottlenecks
How do you find the bottlenecks in the process? This is exactly why we have big visible boards for tracking work items instead of just using online tools! It also helps if you break your tickets down into smaller tickets so that you can actually know when things get stuck. If all of your work items take a week long and three days in your developer doesn't really have much to show for it, are they really behind or do they just need to hook everything up so that you can see it work? You don't really have a good way to tell (other than asking and hoping that the developer can accurately and honestly give you the right answer).
We also want to find waste in the process. Usually this comes in the form of waiting. For example, waiting for answers from the business on requirements questions, waiting for testing environments to get fixed so that testing can start, waiting for management to make decisions, or any number of other problems. It's impossible to eliminate all of these, but we can try to reduce them by communicating and finding creative ways to make things move better.
Think of the end of the iteration like a release date. Maybe you will actually be releasing to production. Either way, the goal is that functionality that goes into the iteration gets done. And by done, I mean all the way done. That means, that it's developed, tested, and the users want to sign off on it. If you have another definition of done, you might be lying! When management hears "done", they think that you don't have to do any more work on it. So if you still have more work to do, that's time that they aren't accounting for in their mind, so now you're in a tough spot.
As you get towards the end of the iteration, you need to make sure that everything that is going to be developed this iteration also can be tested by the end of the iteration. If you want to get a feature done by the end of the iteration, you can't have developers checking in changes on the last day of the iteration if QA needs 2 days to test it because they won't have enough time. On our two week iterations, usually we are cutting off checkins a day or two before the iteration ends, depending on how QA is doing. Developers might even help test if QA gets behind and can't get it all done. Typically that doesn't happen, so developers can keep working, but maybe they don't check their code in until the iteration is over (or check it into a branch). This ensures that the QA team has enough time to test everything that is going into the iteration.
Be creative!
Every project is different, and every project will have it's own unique set of problems, many of which you have never encountered before. At this point, your intuition needs to take over. Don't underestimate the value of intuition and common sense! You can read all the books and blog posts that you want, and many of those will have good ideas, but it's up to you to apply the ideas and tailor them for your situation.
Read the next post in this series, Estimates.
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
One thing that you'll find on pretty much every Agile project is some kind of card wall where features are tracked.
When I started working on Agile projects several years ago, I didn't quite understand the purpose of the card wall. I thought, wouldn't you rather just track everything in some online tool?
While tracking things in an online tool is still a good idea, the Agile card wall gives you a level of transparency that it's difficult to get from an online tool. With a good card wall, you can easily see what everyone is working on, what still needs to be worked on, how long the remaining work might take, and what's blocking your progress. There is so much to keep track of on a software project, and it really helps when you have a visual aid that can help keep everything in front of you so that you don't have to juggle everything in your mind (or some online tool).
The trick is to tweak your card wall to give you the most transparency as possible. Here are some things that I've found help me get the most of my card wall.
Everything is a task
Everyone puts development tasks on their card wall. However, not everything that your team does could be categorized as a deliverable feature. In fact, there are lots of other things that you might have to do:
- Write up documentation on a wiki
- Onboard a new team member
- Set up a CI build
- Get ready for a demo
These are all tasks that are completed by development team members that take a measurable amount of time. So why not create a card and put them on the board? Maybe you use a different color card to indicate that it's an internal task. This gives you two benefits — you know what people are working on and you can use the estimate to gauge how much work is left to be done.
Make card walls for your entire team
If our development card wall can help us track what developers are working on and how much work is left, why not create card walls for the entire team? You could have a card wall for BA requirements gathering, QA creating test plans, project management tasks, or some mini-project that you want to track separately. You get the same benefits that you get with a development card wall — you know what people are working on, you can easily see the status of the effort, you can prioritize the backlog, and it can help you get an idea of how much work is remaining.
Make problems obvious
Your card wall should alert you to any problems and blockers as soon as possible, so that you can remove any blockers and constraints that could keep your team from being able to do their job. Some ways that you can do this:
- Create a separate section of your card wall for blocked items
- If something is blocking a feature, put a post-it note on the card and write what the blocker is
- Structure your card wall so that you can see problems immediately just by glancing at it
Let's look at some examples of some simple card walls and we'll interpret what we see.
Example #1
In this example, we can easily see that we are either developing things faster than we can test them, or things are getting stuck in testing due to bugs. We may need to assign more people to testing or work on reducing bugs.
Example #2
There are a lot of features that are blocked. We should try and address the blocking issues and look and see if there is some greater problem that is causing things to get blocked. Maybe we need to write better features, or maybe we need to get more time from people in the business who can answer questions.
Example #3
We don't have much in our backlog, so the developers are going to be out of stuff to do really soon. We may need to get more people working on requirements gathering.
Example #4
Things are flowing pretty smoothly. We have a good sized backlog, no blockers, the work is evenly distributed, and we're getting a lot done.
The key is that we want to see problems as soon as possible so that we can take the necessary steps to correct the problem and keep things moving.
Address technical debt as part of the process
As much as we hate to say it, sometimes it makes sense to shove in lower quality, untested code in order to meet a deadline. I don't like having to do this at all because of the risks, but when this happens, keep track of all technical debt that will need to be fixed and create separate cards for fixing it. Make these cards a different color so that they stick out. Then use your board to explain to your manager or project sponsor that you're going to need some time to go back and fix the technical debt. Many managers want to pretend that the work is done once you release and will convince themselves that they can just move on without addressing the technical debt. You know better, and it's your job to state that case and show why it's important.
Refactor your card wall
Your card wall is yours. You create it, you manage it, and it belongs to you. Don't be afraid to rearrange and refactor your card wall so that it can better meet your needs. Don't make excuses like "we've always done it this way" or "we read a book that said to do it this way" or things like that. Your process and tools need to serve you not the other way around.
Read the next post in this series, Managing the iteration.
« Newer Posts — Older Posts »


text:
Just a simple mountain-style logo for my next theme, currently in progress.
keyboard shortcuts:
L or F like
post comment
Show and tell for designers
What are you working on? Dribbble is a community of designers sharing screenshots of their work, process, and projects.
Copyright © 2009–2016 Dribbble LLC. All screenshots © their respective owners. Shipped from Salem, Mass. USA.

subset: commoncrawl


text: Dogwood Motel WEBSITE ADD TO Trip Planner Cable television, outdoor pool, microwaves, refreshment area; complimentary morning coffee in the lobby Get Directions Gas Calculator The pet-friendly icon means that any portion or all of the listing accepts pets. Please check with each individual property for rules and regulations. The handicapped accessible icon notates listings that are either partially or fully accessible. Please check with the property or properties you're interested in for specific information. Details Website: http://www.dogwoodmotelonline.com Phone: 870-269-3847 Email: email@example.com Fax: 870-269-2997 Address: Ark. 14 EastMountain View, AR 72560 Payment Accepted: VisaMasterCardDiscover Card Facilities & Features: Lodging Sleeping Capacity: 30 No Smoking Recreation Things to Do In Mountain View EXPLORE


text:
Click a Suffolk
mattress retailer on the map or in the list below to find out more information,
including brands they carry, current mattress promotions, consumer reviews, store location details, and more.
Mattress Stores Near Suffolk, VA (3 found nearby) Expand search to 50 miles
|Click name for Retailer Info
|Click address for Store Location Info
|Carter Quality Showroom
|186 E Washington St, Suffolk, VA show on map
|show on map
|Carter Quality Showroom
|189 E Washington St, Suffolk, VA show on map
|show on map
|Mattress Discounters
|6255 College Dr, Suffolk, VA show on map
|show on map
|Schewel Furniture
|944 N Main St, Suffolk, VA show on map
|show on map
|View closed mattress store locations in Suffolk, Virginia
Mattress Shoppers: See a store in our area mattress info that's been closed or renamed? Know another mattress store near , VA that should be included on this map? If so, please let us know about it! Your feedback can be sent to: storefinder [at] goodbed [dot] com.
Mattress Retailers: See outdated store details for one of your mattress stores near , VA? Claim your store profile here. Have a mattress store in the area that's not listed on GoodBed yet? Add a new store profile here.


text:
I find it very strange that since I've installed the latest wordpress version, all my links have pop ups when I click on them. Is it because of the new version or something else I'm not aware of? Can someone help me please? How can I get rid of the link pop ups? It's very annoying.
My blog is http://www.mycasserole.net


text:
Dior is pleased to offer complimentary shipping for orders of $50 or more. Simply create an account and click yes to become a Dior Diva and complimentary ground shipping will be automatically added to your order.
An email has been sent to to your address. Please check your mailbox.
Complimentary exclusive Dior gift wrapping
Complimentary trial sizes or your choice
An elegant gala spirit in an intense evening fragrance, swathed in mystery. This interpretation of Lavender in chiaroscuro reflects the atmosphere of the Château de la Colle Noire, an estate owned by the Designer, which is located in the Provence region.
Eau Noire is surprising because it is almost an oriental fragrance for men. To me, it is particularly addictive.
François Demachy
Subscribe to email alert
Thyme is an aromatic plant rich in essential oils. Its immediately recognizable scent diffuses a fresh and delicate smell that gives Eau Noire aromatic, intense and enigmatic head notes.
Floral and aromatic in one, Luberon Lavender essence is obtained through steam distillation of the freshly cut flowers. Mild and fresh with a hint of tobacco, lavender takes on a nocturnal feel with sensual, enchanting notes in Eau Noire.
Liquorice is a perennial plant with aromatic roots, native to Southern Europe. Liquorice extract adds a spicy and delicious facet that unfolds in the base notes of the fragrance.


text:
More information about "vegas"
Below you can find your competitors – also show yourself to vegas!
Click here for your Exposé
Gady Medrano
03.02.2013 - have made Gady Medrano among the top realtors in the Las Vegas metropolis, as well as a highly beloved presence on A […] &E's website. …
Rico Elbaz
Vendor details for Rico Elbaz, Dancers in Las Vegas, Las Vegas - Henderson Nevada Dancers, Las Vegas - Henderson Nevada Wedding, Las Vegas - Henderson Nevada...
Oscar Goodman
18.06.2009 [Journal] - Stavros Anthony sworn in as Las Vegas councilmanLas Vegas Review - JournalStavros Anthony, left, talks with Las Vegas Mayor Oscar Goodman …
Brendon Urie
See guides for the best Las Vegas shows, clubs and dining
Dennis Ficor
Watch Golden Nugget, Las Vegas Nv. Dennis Ficor @ Golden Nugget Las Vegas · Watch Dennis Ficor @ Golden Nugget Las Vegas ...
Anuranjan Bist
Anuranjan Bist - Medical Professionals in Las Vegas, Nevada: Anuranjan Bist in Las Vegas, Nevada. Doctors and Medical Professionals in Las Vegas, Nevada (89101). …
Celine Dion
19.02.2013 - refunds. It's currently unclear if Celine Dion intends to rescheduled these performances. The Las Vegas Sun reports […] disappointed that Celine …
Yvonne Hubrechtsen
... P, LAS VEGAS, NV, P Hubof. Hubrechtsen, Yvonne, LAS VEGAS, NV, Yvonne Hubrechtsen. Hubrechtsen, Yvonne, LAS VEGAS, NV, Yvonne Hubrechtsen., vegas
Robert McWilliams, Director of Photography @ Robert McWilliams Productions, Danville
For A Job, "Done Right" "On Time" and "On Budget"
Network Level News Productions, Northern California, Francisco, San Francisco, High Definition Camera, Definition Camera, Camera Crew, California and Beyond, Beyond, Vegas
Ofuoma Odje, Principal @ OCAA SOLUTIONS LLC, Henderson
IT Consulting Services Holdings, Universal Healthcare, Details, Email, SEACOR Holdings Inc, SEACOR Holdings, Phone, Universal, United, Vegas
Steve Esh @ las vegas
Melissa Hunkin, Public Safety @ las vegas, nv
Vegas, SAN Mateo, Plenty, McCoy, August, California, Annual
People by job: ABCDEFGHIJKLMNOPQRSTUVWXYZ People by company: ABCDEFGHIJKLMNOPQRSTUVWXYZ


text:
Vancouver, BCCanada
October 4, 2010
No introduction yet
Explore Real Estate Investment opportunities, learn how to evaluate and finance from the pros, share and trade information. Novice and professionals all welcome. Professional advisory forums and opportunity presentations planned.
Meetup members, Log in
By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy


text:
Video Industry News Video Company News Technology Industry News Technology Company News Novelty Industry News Novelty Company News Gay Industry News Gay Company News Legal Industry News All Company News
Released: Jan 01st, 2005
Running Time: 60
Company: Starr Productions
Cast: Elizabeth Starr, Tall Goddess, Kat Kleevage, Annie Body
Critical Rating: AA
Genre: Specialty
Have a novelty section? This goes there.
Four ladies done up all vintage-like chainsmoke like it was going out of style. There's nice art direction here, real classy, but the production is lacking in creativity elsewhere. The ladies and their augmented breasts simply puff away with little variation. Yes, Annie Body moistens her deathstick with her little red snatch, but that's it folks. Still, very nice background title for parties and such.


text:
FX August Luncheon
The Freelance Exchange of Kansas City
Friday, August 22, 2014 from 11:30 AM to 1:00 PM (CDT)
Who's Going
Loading your connections...
3 of your friends are going. Share it to get more people on board! Share
Sara Haughty
San Francisco, California
San Francisco, California
Luke Picard
London, United Kingdom
London, United Kingdom
Rick Vespucio
Florence, Italy
Florence, Italy
Event Details
For details about this event, please visit http://kcfreelanceexchange.com/2014/fx-august-luncheon-how-to-grab-the-attention-of-a-prospective-client/
Have questions about FX August Luncheon? Contact The Freelance Exchange of Kansas City
When & Where
The Burg and Barrel
7042 W. 76th Street
Overland Park,
Friday, August 22, 2014 from 11:30 AM to 1:00 PM (CDT)
Add to my calendar
The Freelance Exchange of Kansas City
We are Kansas City's outsource resource—a professional trade organization of self-employed individuals in the advertising and marketing industry. Our members are some of the best advertising and marketing talent in town, and they have joined FX to become more business savvy, share best practices, and expand their network.
FX August Luncheon
Things to do in Overland Park


text:
Patient Comments: Insulin Resistance - Describe Your Experience
Please describe your experience with insulin resistance.
Comment from: Karen, 65-74 Female (Patient) Published: August 17
I am a female, 68 years old. I'm 5'3" and 113 lb. I exercise every day and am very active. Recently I had A1C of 5.7 and blood glucose of 106. In everything that I have read regarding pre-diabetes they tell you to lose weight, exercise, give up soda, sweets, etc. My frustration is that I'm already thin, very active and have never smoked or consumed soda. I also don't drink alcohol.
Comment from: jess, 13-18 Female (Caregiver) Published: December 17
Since my daughter was born she was always larger in size than she should be. With every effort made in trying to get an answer I was told she should stop eating muffins. My child has been through so much and is continuing to struggle with insulin resistance. She has been on medication for the past 4 years, she has exercised and dieted and still she cannot lose weight. She loses some weight then cannot lose anymore. She is 15 years old and it saddens me to think there is no real answer for this. Doctors and professionals really need to investigate until something real is found.
Comment from: Mary, 45-54 Female (Patient) Published: August 23
I was recently diagnosed insulin resistance. It came as quite a shock. I have yearly physicals & my blood work was always excellent. Well, of course my fasting sugar was normal - but my pancreas was working overtime to get it there. I went to a nutritionist because I always felt that I couldn't lose weight and steadily, but on 10 pounds a year for 6 years. So glad that I went to see the nutritionist. I would have been in the dark until I actually had diabetes. I chose to alter my diet & not take medication. My intake of sugar is around 20g per day. I am working on increasing my protein intake. It's been a little over a month, and I'm not craving sugar (did not add any artificial sweetener either), working on getting carbs even lower although I have given up most bread products. I will get wheat if I need to. I am exercising regularly now. The diagnosis sufficiently scared me to turn me around. My mother is diabetic and obese, my grandmother is diabetic and has health issues related to diabetes. I don't want to be on medications for the rest of my life. My nutritionist believes that I will get the insulin resistance under control. I miss fruit and Starbucks, but living longer is more important. I wanted to tell everyone I know to get their insulin level checked, but most people live in a state of denial - i'll pretend this isn't happening and ignore it as long as possible. I track all my food with My Fitness Pal app, it is really helpful.
Comment from: claytonokc, 55-64 Male (Patient) Published: June 22
I am insulin resistant and have been for the past four years. I slipped a disk and then had a spinal fusion. I gained 100 pounds in three years after the back problems, and I had a brace to walk for almost a year. I have -- in the past two years -- lost 66 pounds and work out regularly for 45 minutes or more on my exercise bike. I have gone from eight pills a day to only one with diet and exercise. I have sleep apnea, and if I loose 40 more pounds, I may be able to get off the pills and CPAC. I have to watch and count everything I eat and I am working for that goal.
Comment from: mis-diagnosed, 25-34 Female (Patient) Published: June 01
I am 26 years old and was just diagnosed with insulin resistance. When I was 16, I was diagnosed with polycystic ovarian syndrome and congential adrenal hypoplasia. I was told that I would not be able to have kids and that I needed to wear a medical tag for the adrenal stuff. I have gone for 10 years now, not knowing that I had the insulin resistance and thinking that I could not have children. I found out all I have to do is exercise, watch carbohydrates and take Metformin and it will all be better. Metformin gives me diarrhea and emotional ups and downs, but I am trying to hang in there with it because my doctor said it is the best med for this problem. I also found out that I can have children; there is nothing wrong with my hormone levels for that. I have been obese, had skin problems, and excess hair like you wouldn't believe because I was mis-diagnosed. I could have had all this under control and probably had a child by now if I had the right diagnosis. I am still a little mad, but extremely thankful that I was finally diagnosed correctly. It has been about 2 months and I have been eating better, taking medications and exercising. I have lost 20 lbs. I just hit the 20 lb. mark today. I have looked back at all the signs and symptoms I have had over the years and wonder why nobody found this earlier. I have eaten so many carbohydrates over the years because I have had such an intense craving for them. It was nothing for me to sit and eat 3 or 4 candy bars in one setting, bread balls (gross huh), anything that had sugar and carbohydrates. I have trouble going to sleep and getting up in the mornings, trouble with fatigue. I do have a lot more energy and I am a lot happier as long as I don't have more carbohydrates then I am suppose too. I tend to get a little emotional and cranky if I sneak some extra carbohydrates. I just hope that people will read this and see if it sounds like them and maybe get help before something serious occurs.
Patient Comments
Viewers share their comments
Insulin Resistance - Symptoms Question: What were the symptoms of your insulin resistance?
Insulin Resistance - Causes Question: What do you suspect or know was the cause of your insulin resistance?
Patient Comments are not a substitute for professional medical advice, diagnosis, or treatment. Never delay or disregard seeking professional medical advice from your physician or other qualified health provider because of something you have read on MedicineNet. The opinions expressed in the comments section are of the author and the author alone. MedicineNet does not endorse any specific product, service or treatment.
If you think you have a medical emergency, call your doctor or 911 immediately.
Report Problems to the Food and Drug Administration
You are encouraged to report negative side effects of prescription drugs to the FDA. Visit the FDA MedWatch website or call 1-800-FDA-1088.


text:
You are using an outdated browser. Please upgrade your browser to improve your experience.
musicians corner
Musician's Corner: iRig HD Connects Your Instrument With High-Quality Sound, A Hands-On Review
Check out our review of IK Multimedia's newest guitar-to-iOS interface adapter.
Lory Gil
| August 6
Musician's Corner: Tune Your Axe In Style With Tunable – Instrument Tuner
Tuning an instrument has never looked so good.
Lory Gil
| July 29
Musician's Corner: Chordion Makes Music Easy To Play
Take your iPad to the next level, musically, with this synthesizer app.
Lory Gil
| July 15
Musician's Corner: Become A Shredding Guitar God With Lick Of The Day
Learn guitar, one day at a time, with this video-based music lesson app.
Lory Gil
| July 1
Musician's Corner: The Nessie Microphone Turns Amateurs Into Pros – Hands-On Review
Blue Microphones recently launched Nessie and we got a chance to check it out.
Lory Gil
| June 25
Musician's Corner: Capture Song Ideas With Song Keeper Free
Sometimes, you just need a quick and easy way to get your song ideas recorded.
Lory Gil
| June 17
Musician's Corner: Musyc Makes The World Go Round
This week, Apple gave a music app the Editor's Choice award and we have something to say about that.
Lory Gil
| June 3
Musician's Corner: Turn Music Into A Social Occasion With UE BOOM – Accessory Review
We got our hands on Logitech's newest iPad case and we've got an in-depth review for you.
Lory Gil
| May 27
Musician's Corner: iKlip 2 and iKlip Studio For Mini Now Shipping
Check out the newest products that are ready to ship from IK Multimedia.
Lory Gil
| May 20
Musician's Corner: Learn How To Listen To The Notes With Beat The Melody
Hone your pitch recognition skills with this fun music education app.
Lory Gil
| May 13
Musician's Corner: Apple Makes Jamn App Of The Week
See why Apple chose to spotlight this music theory and scale practicing app this week.
Lory Gil
| May 6
Musician's Corner: Access Your Membership On The Go With ASCAP Mobile
Keep your musician's "cred" with you at all times with this mobile membership app.
Lory Gil
| April 29
Musician's Corner: Hit The Beat On - Time With TheDrumDictionary
Practice your paradiddles with this drum sample app.
Lory Gil
| April 22
Musician's Corner: Create Music Using Sounds From Around The House With Yellofier
Sample your cat's meow and turn it into an electronic song with this music app.
Lory Gil
| April 15
Musician's Corner: Motörhead Phones Push Your iPhone 'Over The Top' – Hands-On Review
Motörhead has their own brand of headphones and we have a review of the top of the line.
Lory Gil
| April 10
Musician's Corner: Looking For A Good Show? We Have A Few Options
Find out what is going on with your local music scene with these location-based apps.
Lory Gil
| April 1
Musician's Corner: Shred Along To 'Peace Sells' With David Ellefson Rock Shop
If you've always wanted your bass guitar to sound like it belongs in Megadeth, there's an app for that.
Lory Gil
| March 18
Musician's Corner: Sing And Play Piano To Your Favorite Pop Songs With NoteStar
Play along with your favorite pop songs with this innovative sheet music app from Yamaha.
Lory Gil
| March 11
Musician's Corner: Bringing Back The Wurlitzer with iLectric Piano
We have an in-depth review of IK Multimedia's newest app, plus two copies to give away.
Lory Gil
| March 4
Musician's Corner: Find Dozens Of Versions Of Your Favorite Songs With Remixes
Dig through thousands of remixes to find new versions of old favorites with this music discovery app.
Lory Gil
| February 19
Musician's Corner: Make Music While Playing In Water With Aquasonic
For this episode of Musician's Corner, we show you how to relax and make music at the same time.
Lory Gil
| February 11
Musician's Corner: Eventide H9 Harmonizer Makes a Splash at Macworld/iWorld
For this episode of Musician's Corner we visit Eventide's booth at Macworld/iWorld to find out more about the H9 Harmonizer.
Lory Gil
| February 4
Musician's Corner: Create Custom Chord Charts With Chord App
For this episode of Musician's Corner we work on finger placement for chords.
Lory Gil
| January 28
Musician's Corner: You Must Practice Your GuitarNotes If You Want To Be Great
For this episode of Musician's Corner, refresh your memory with this guitar game.
Lory Gil
| January 21


text:
Louisiana Gov. To Talk ASG With Silver WNBA Rescinds Players' T-Shirt Fines Goodell Has Room To Improve Image League Notes NBA Officially Pulls '17 ASG From Charlotte Source: New Orleans Leads To Host '17 ASG WNBAers Continue Stance Against Racial Injustice NFL Parts Ways With Controversial Doctor Rob Manfred Opines On MLB Issues Bettman, Manfred Happy With MLBAM Deal
Upcoming Conferences and Events
SBD/Issue 15/Leagues & Governing Bodies
Little Promotion Evident In Finland For Blackhawks-Panthers
Published October 2, 2009
|This Weekend's Panthers-Blackhawks Games
First NHL Regular-Season Games In Finland
IMPACT QUESTIONED: In Detroit, Chris McCosky writes under the header, "Swedish Opener Makes No Sense For The NHL." The Blues and Red Wings are playing two games in Stockholm on Friday and Saturday, and there is "nothing to be gained, from a business standpoint, by playing games abroad" in Stockholm, Helsinki "or wherever." McCosky: "How can the NHL be thinking global when it is struggling in its main market? There is no chance the NHL is expanding to Europe. There isn't going to be any spike in merchandise sales over here" (DETROIT NEWS, 10/2). The South Florida Sun-Sentinel's Ethan Skolnick wrote there is "some international marketing benefit" to playing overseas, but that "comes with the debasement of the product through the creation of an inequitable schedule." The NHL "needs to sell its product to this country first." The L.A. Times' Helene Elliott wrote the "real motivation ... is business," as Finland and Sweden are the "top-ranked countries in terms of overseas visitors to NHL.com." Meanwhile, the Hartford Courant's Paul Doyle wrote it is "not a terrible idea to spread the NHL brand to Sweden and Finland," but "forcing four teams to shift training camp overseas and open their schedule in another part of the world seems unfair to players and fans" (LATIMES.com, 10/1).


text:
292 Academic & University Jobs in Europe
Academic mobility between Europe's higher education institutions is facilitated by the European Higher Education Area, which includes 49 countries and promotes Europe as a world education destination, increasing its popularity with international academics and students. Europe's universities are under increasing budgetary strain but leaders recognise the importance of recruiting top-quality staff to maintain the highest teaching and research standards. It is widely agreed that a knowledge economy is essential in tough economic times, and Europe's universities are gaining ground on US institutions in the Times Higher Education World University Rankings. Europe has 345 universities in the world top 800 (2015-16), with institutions in Germany, the Netherlands and Switzerland doing particularly well.
Browse jobs by Job Type
Browse jobs by Academic Discipline
Browse jobs by Location
- Denmark 9
- Germany 3
- Ireland 7
- Luxembourg 1
- Sweden 2
- Switzerland 18
- United Kingdom 252
Career news and advice
The public should help academics to define 'impact'
Many more of the general public should help to plot the course of research, argue Christiaan De Beukelaer and Jan Baetens
After Brexit, will UK universities set up EU branch campuses?
Sector experts debate whether continental outposts would help to mitigate any decline in student recruitment
Interview with Jean-Claude Worms
We talk Brexit, astronaut aspirations and the difficulties of surfing in a landlocked region
- Post a job with Times Higher Education
- Monitor your response live
- Receive any applications direct to you
Featured recruiters
For all enquiries regarding packages, rates and the best way to target your audience, speak to the hiring solutions team:
Nick Davis
+44 (0) 203 194 3325
Dominic Garcia
+44 (0) 203 194 3286


text:
Policy Reports
NCPA studies generally break new ground on policy issues. A study seeks to cast new light on an issue and to stimulate policy-makers and others to think of new, innovative solutions to the problems associated with the issue. Studies may combine several elements of analysis, including original research, reviews of academic literature, creative approaches for solving public policy problems, and economic modeling.
The Clinton Health Plan
President Clinton has offered the nation a dramatic health reform plan that promises universal coverage, benefits as comprehensive as those of Fortune 500 company plans and lower costs. The actual re…
A Primer on Managed Competition
Managed competition would make no sense unless most health care were delivered in health maintenance organizations (HMOs), employing the techniques of managed care. That is why most proponents of mana…
Inefficiency in the U.S. Health Care System:
We do not always spend health care dollars in the most productive way. The way we pay for health care encourages both patients and physicians to overuse resources. On the average, every time a patient…
Using The Private Sector To Deter Crime
Since 1965, the share of gross domestic product (GDP) devoted to the U.S. criminal justice system has more than doubled. Yet the amount of crime reported to the police is near an all-time high and the…
Texas Health Care Reform: The Best and Worst Ideas
This study examines the most serious health policy problems facing Texas and analyzes the best and worst proposals for state health care reform.
Rethinking Robin Hood
We have analyzed the distribution of education dollars before and after Texas adopted the "Robin Hood" system of financing schools -- a system under which taxes are raised countywide and then distribu…
Economic Impact Of Government Spending: A 50-State Analysis
Econometric studies cast serious doubt on the benefit of most government spending. They show little relationship between most government spending - including education and highways- and economic growt…
How Our Health Care System Works
A new model of the medical marketplace shows that U.S. health care costs are rising because Americans are overinsured and that government policies are the primary reason. The most important change in…


text:
+ Post New Thread
Hi Animal ,
I work with ExtJs and Ext GWT applications.
I have a requirement to configure swf uploader with GWT.
I followed the below link and...
Since RadioGroup was removed in GXT3, how can I group some Radio-Widgets?
I try to use the designer view with Eclipse (Indigo version), but every example that I try, I have the following error:
Error loading...
I've created an application in a BorderLayoutContainer, with some buttons on top (like a toolbar) and a TabPanel on center. When I press a...
Hello all!
I was wondering how can one set more than one leaf/folder icon for the Tree widget in gxt v3? The only way I've found out is by...
I extend EditorGridPanel
some.CartGrid = Ext.extend(Ext.grid.EditorGridPanel, { ...
How can i override "refresh" method of my component...
Hi Guys,
I saw some demo code at mvp4g web site, and mvp4g can work with GXT2 together,
I want to use mvp4g with gxt3 dp5, does anyone try with...
How can I align buttons from Cell Grid Examples in GXT3 Explorer in the middle of grid cell not on the left?
I have a maven project with these dependencies:
please help me~
How do I create a red line in cell ?
Hi guys, excuse me for my bad english :)
I have a Window that can open one or more Dialogs. I need to have all open dialogs "always on the top",...
I am trying to configure line chart and bind it to store. It works but the only problem is that chart displays legend even before first point...
Hey there,
Apologies if this has already been answered somewhere, but I couldn't find anything about it. I was poking around the 3.0 beta and I...
I am new to Ext.Js and have come across a problem. Currently a program I am working on has a date field. When you type in an invalid date (such as...
I've made some tests with the preview of ext gwt 3 (snapshot dp5). For a form I've used the SimpleBeanEditorDriver for data binding. This works fine...
I'm using UIbinder with gwt 2 and when I look at the develop examples I see
that there is only java code samples, no Uibinder..:-/...
In Grid component, When Horizontal scroll bar is not display, there is why space display at the end of last column. How to remove that.


text:
From the Spice Cupboard: Fenugreek
Both the seeds and the leaves (fresh or dried) of the fenugreek plant are edible. The seeds are small, hard, and have a shrunken rectangular shape similar to dried beans or corn kernels. The leaves are flat and spear-shaped, and radiate out from a central stem. While both smell like caramel or maple syrup when heated, their taste is rather bitter, like burnt sugar.
Fenugreek is most widely used in Indian cuisine, though it's also found in North African and Middle Eastern dishes. It's used in many curry mixes, dry rubs for meat, and some bread recipes. A pinch can also be sprinkled over yogurt, cooked greens, or sauce. Apart from the unique flavor and aroma, fenugreek seeds can also contribute a thick slippery texture to dishes, just like okra.
The fenugreek being processed by that New Jersey plant was probably destined for artificial maple syrup or butterscotch syrup. Even if you've never heard of fenugreek, it's likely you've experienced at some point in this form!
Look for fenugreek at Middle Eastern groceries. It sometimes goes by the name "menthi". You can also find it online at places like Penzeys Spices.
If you'd like to give fenugreek a try, check out these recipes:
• Marinated Lamb Chops with Fenugreek Cream Curry from the Food Network
• Steamed Rice and Bean Dumplings in Spicy Lentil and Radish Sauce from Epicurious
• Salmon Curry from the Boston Globe
How do you use fenugreek in your cooking?
Related: Kitchen Ambition: Learn How to Cook Dosa
(Images: BBC Good Food)


text:
Eric Leschinski
Help me make documentation for
apache-kafka on stackoverflow!
This is what I'm doing with my time:
I'll be the watcher, of the eternal flame:
Because from the darkness comes light, and from the light, darkness:
Upper crust of the upper crust hides in the landfills of the mediocre.
If you're going to play with magic, you should know what you're falling for.
Behavioral evolution:
I need to point these Machine Learning algorithms I've got working in Java, GNU Octave and Python 2.7 to Oncology and help doctors detect cancers and tumors far earlier than ever thought possible. Preventative medicine, not reactive medicine.
With your understanding of the interior workings of the cancer or tumor cell, combined with my ability to collect data and format them as training rows and feature data, we might be able to predict cancer and tumors earlier than ever thought possible. Perhaps even detecting it at the level of the DNA itself. Do you have access to large quantities of non cancerous and cancerous DNA data files? Please message me so we can get to work.
Too much good causes evil, and too much evil causes good, this is because of the first law of thermodynamics. Every action has an equal and opposite reaction.
Modern day tower of Babel: https://youtu.be/JOxSnB9ST2c?t=9m1s
Python's biggest design flaw: http://stackoverflow.com/questions/1132941/least-astonishment-in-python-the-mutable-default-argument
What is your plan for reclaiming the Inhospitable surfaces of planet Earth? https://youtu.be/S1oX9L6e6_Q?t=32m31s
Another flaw in Python: http://stackoverflow.com/questions/240178/python-list-of-lists-changes-reflected-across-sublists-unexpectedly
In my 18 years of formalized education so far CS7641 at gatech is the best class I've taken to date: https://www.youtube.com/watch?v=kOIKduAOD5k
Oh look, another design flaw in python -6 isn't actually -6, but indeed -5 is -5. derp: http://stackoverflow.com/questions/11476190/why-0-6-is-6-false
It's an exciting time, like the time of the invention of electricity and the invention of the integrated circuit. Computers are better at coming to an understanding about things faster and better than humans ever could.
If we do not integrate these machines into our minds, eventually humans will all be unemployable, humans simply can't do any repetitive motion or learning task as good as, or as fast as a computer could be programmed to learn to do.
- Allston, MA
- sentientmachine
- Member for 4 years
- 104 profile views
- Last seen Jul 21 at 15:40
Top Posts (15) All Questions Answers | Votes Newest
Badges (38)
Gold 3
Silver 12
Bronze 23


text:
Why is mundines mouth worse than these blokes actions
View Single Post
fast hands
ESB Senior Member
Join Date: Jan 2009
Posts: 1,371
vCash: 1296
Re: Why is mundines mouth worse than these blokes actions
Originally Posted by
rusty nails
john stephenson, timana tahu
Steffensen is a good call Rusty but he's originally from South Africa.
Athletics Australia has recently suspended him for 6 months after finding his claims of racism and villification in the lead up to the London olympics unsubstantiated.
Steffensen was dirty that teenager Steven Solomon had been selected ahead of him in the 400 metres at the London olympics. Solomon went on to make the olympic final.
In 2010 Steffensen copped a 3 month ban for making similar accusations.
Many would remember Steffensen's effort last year in the Stawell Gift when he ran dead after realising he wasn't making up any ground on the front markers.
He has had his snout firmly planted in Athletics Australia's trough for more years than he deserved.
Steffensen and Mundine are like peas in a pod. They are both outrageous self promoters who don't give a rats who they offend.
Good riddance to this pair of serial pests.
[ it has been reported that Steffensen could be considering a career in boxing ]
fast hands
View Public Profile
Find More Posts by fast hands