It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I was trying to think of some non-CS related applications of the stack concept in the real life, unlike function calling, parsing, DFS, etc. but couldn't come up with any.
For queues, I can think of several, e.g. assembly line in a factory, customer servicing in banks etc. but am not able to think of similar ones that work only via pushes & pops in the non-CS part of our daily life. Can someone please suggest somethings?
Your job.
When reducing staff, many companies are bound by agreements and regulations to use the "Last In First Out" to decide who goes and who stays.
The accountants like this because shorter service equates to lower redundancy payments. The unions or other staff representatives like this because it removes any possibility of favoritism and prejudice or victimization from the choices.
There is one real-life example that even uses the FIFO and LIFO terminology: accounting.
Whenever a company buys supplies, it counts those supplies as expenses not when it buys them, but when it uses them. For instance, a company may buy a thousand pencils today, but use them over a year, and for financial reporting purposes it can report that over a year.
But what if the company buys pencils today and a month from today, and the price has changed in the meantime? For financial reporting purposes, the company has to pick a price for the pencils as it uses them. A year from now, as it uses the last of the thousand pencils, it could use the price for today's pencils, or it could use the price for next month's pencils.
Accounting standards don't give the company leeway to make up prices, so the costs have to come from real supplies (and you can't use one month's price to expense both shipments of supplies), but in the US at least there is some leeway for the ordering of the supplies for accounting purposes. Under FIFO, the pencils are assumed to be on a queue: the oldest pencil is expensed first. Under LIFO, the pencils are assumed to be on a stack: the newest pencil is expensed first.
Um, well, the reason it's called a "stack" is because it is like a stack of paper on a desk. You "put" papers on the top of the stack (push) and "take" them off of the top (pop).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am a newbie to Agile methodology and I somewhat am afraid when I am working on Jira User Stories assigned to me. I have below questions.
How to provide estimate for a task or user story assigned to me? I mean what all factors should I consider? There are some stories for which I have to do some research and then develop. While other members in the team provide estimate in days for their user stories, I feel afraid to ask for more.
Once I am working on the user story, how should I log my work. I mean, once I am researching for the topic, does those hours also count or only those hours when I am actually writing code. Also, out of the total 9 hours per day, do I have to log 9 hours complete for the day or just those hours in which I actually worked and not counting lunch time and meeting times.
If I don't log 9 hours per day, the number of days I will work will surpass the assigned number of days. Is that so?
Any help is appreciated.
How to provide estimate for a task or user story assigned to me? I mean what all factors should I consider? There are some stories for which I have to do some research and then develop.
An approach that works for me is to start with a guess of how long something will take and then add some extra time for:
Any uncertainty
Unusually complex tasks
Tasks with lots of dependencies
While other members in the team provide estimate in days for their user stories, I feel afraid to ask for more.
My advice would be to under promise and over deliver. For example, if you estimate 2 days and it actually takes less than 2 days then people will be happy. If you continually underestimate how much time it takes to do tasks then it will be disruptive and unpopular.
Once I am working on the user story, how should I log my work. I mean, once I am researching for the topic, does those hours also count or only those hours when I am actually writing code.
Everything you do towards completing a task should be included in the estimate. That includes if you have to do research or background reading. Remember that when you learn something new it is valuable to your organisation as it improves your capability. They should want you to be learning!
If I don't log 9 hours per day, the number of days I will work will surpass the assigned number of days. Is that so?
In development we usually estimate in ideal days. An ideal day imagines if you only worked on the one task and had no other distractions. The number of ideal days worked is never the same as the number of actual days worked. It is not unusual for an ideal day to take 1.5 or more real days.
This is what I do in my company:
i. Business requirements gathered from manager/product owner (PO) with businesss owner / stakeholders.
ii. PO and developers list down all the features that are needed to implement, from business scopes into features.
iii. Discussion to put high/medium/low priorities for v1, v1,1, v1,2 and so on (Google Minimum Viable Product (MVP)), agreed by business owner.
iv. Product owner/manager/developers and designer to come out wireframes (usually sketches) with those features discusssed earlier.
v. Confirmed wireframe by product owner and developers with stakeholders, the designer comes out final UI.
vi. Create stories, from there you plan how long each stories. If the feature is huge, make it as Epic, split into smaller stories, and plan the time for implementation (based on the developer who is going to do, NOT your manager to decide your implementation time). If you afraid to ask for more, and if you can't finish the task on time, that's your problem. Always be honest and frank to everyone, that's your team, they won't bite. If you fail, everyone fails. So if you finish earlier, pick new stories inside Backlog, and plan your estimation better in next sprint. You can ask for some "buffer" time to do research on certain features which is unclear in implementation for stories estimation, before implementation is officially started.
Log ONLY your working hours on that stories. Never log your lunch time (of course!). My previous company was doing "realistic" and "honest" Agile, putting realistic estimation of 6 hours/day for developers (admit that devs as human beings are using the rest 2 hours to watch cats videos, drink water, toileting, flirting, chit-chat, slacking etc).
Refer to 2. You should plan your estimation better, based on your experience and ability on spending on your tasks. If you finish all the tasks very earlier than expected estimation time, or over-commit your promise, are considered bad/failed sprint. Improve it on next sprint.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Improve this question
Foreword: One could argue this question would be more at home on Law SE, but considering most lawyers aren't even aware of what a hackathon is, this question has a far greater chance of being properly answered here. If you disagree with that judgement, definitely let me know.
Now onto the good stuff
I personally love hackathons. They're a chance to develop some of the most useful skills in programming, like teamwork, rapid debugging, problem simplification, sleep deprivation tolerance, and that ability to turn an idea into a usable product as quickly and efficiently as possible. And yet there's something nagging at me: at some of the bigger hackathons, genuinely great ideas come about, ideas that could seriously be worth something. For example, Techcrunch Disrupt SF produced BlazingDB, a means of running very expensive database queries through GPUs, which is fairly genius considering any query on a distributed database is basically already a map-reduce operation, and that's just one name from the first hackathon I thought to google.
So who owns the products produced at a hackathon? The host? The creators? The sponsors?
This will be subject to the terms of conditions that you agree on when you join a hackathon. I for example will join a 2 day innovation hackathon next week and had to obey to the rules stated in the confirmation of participation policy.
It should usually look like this:
Confirmation of participation
I confirm my participation in the 'NAME OF HACKATHON' event on 'DATE and VENUE'. I understand that all outputs created at the above hackathon event will be on the basis of the 'NAME of LICENCE' as detailed at 'WEBSITE WHERE TO FIND'. By participating in this hackathon event, I hereby give permission to 'HOST NAME' to use any pictures and videos taken during the event that include myself for the purposes of organization promotional material and publications.
Mine used the following license: https://creativecommons.org/licenses/by/4.0/legalcode
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are in the process of starting to use Scrum (in combination with TFS 2010 and the MS Scrum template) in our company. Since none of us have any experience there are still some questions to be answered.
Since our Product Manager and Scrum Master are non-technical people it would mean that we, the Developers will be part of the meetings that split up the feature requests in small Product Backlog Items. It is my belief that we can do this on our "planning poker" meetings to discuss the feature. But how is this planned in? Let's say that we get a new feature request in the middle of our sprint. (Our sprint will be 80/20 timed.) Should we keep this also into account when planning our sprint, or would it simply mean that the time we spend in that meeting must result in items moved back onto the Product Backlog.
We know we should split a feature up into as many PBIs as we can (and of course, that makes sense) and that a single PBI should not exceed the length of one sprint. That also makes sense. But where should we draw the line? For example, our application communicates with several USB devices. The feature request is that we should communicate with a new device. Implementing this is a 2 part job:
a) add the communication with the device to our USB library;
b) add UI support for this device
Should we split this up into two separate PBIs, or is this one PBI of which we should create multiple tasks?
On a side-note: when a PBI has been added, should we create a task for each PBI when we start implementing it? As far as I see in TFS we cannot set remaining work hours on a PBI. So my initial idea was to create a task for each PBI. But I know some colleagues will find it "a lot of work" to create a task for a PBI that only has one task. How should we handle this?
In Scrum, it is the PO's responsibility to break the features into small-enough user stories. That being said, there's nothing wrong with the PO getting help from the team (or anyone else for that matter) in splitting them. The planning poker session might be a good place to fine-tune the split, due to the team's input on the complexity of each story, but the PO should have a sense of how to split the stories beforehand.
The planning session should take roughly half a day. Definitely not a significant portion of each sprint. Regardless though, the remaining hours in the sprint (e.g. 90-5=85, in a two week sprint) should be the amount of time that the team has to fill with the stories' tasks. Of course, no matter how much time is left in the sprint, any stories that the team can't commit to should be returned to the product backlog; they won't be done in this sprint.
The stories should be sized appropriately, i.e. can be completed in a single sprint. Personally, I prefer to size stories so that a few stories can be completed by the team in one sprint. A good rule of thumb (but not a hard rule, by any means) is to stop splitting your stories when you reach the point that they can be released by the team in 3-5 days.
Though you didn't ask how to split your features and split them along the lines of Core capability, entry barriers, key differentiators, and nice-to-haves.
Regarding Breaking the stories into tasks: You should have at least one task per story. Stories define what needs to be done; Tasks define how. You should probably have at least one task per participating component of the system, as well as one task per actionable item in your definition of **done. If you have only one task, then you probably don't have a definition of done, or your stories are defining implementation, rather than functionality.
With regard to TFS - TFS doesn't change any of the above, though it does support everything I suggested.
Yes, it's better if you create tasks under PBI even if its only one task, because the PBI was made to monitor product progress, it used story points in estimation (Relative Size), but the task is used to monitor work progress, it used hours in estimation, so every work items have different purpose.
1) The time taken to split the stories out will be reflected in your team's velocity so you shouldn't really have to do anything to plan it in. If you are spending say, half of your sprint in story planning/splitting and getting 5 stories done per iteration, then your plans will reflect that. Through the use of retrospectives you can see that spending less time in story splitting will increase your velocity to say, 8 stories per iteration. Keep an eye out for side effects of spending less time splitting stories though so you can see both sides of the coin.
2) Not knowing the application, I would say that one way of splitting this out would be
Alert User When New USB Device Is Inserted (This would show potentially a default icon)
Alert User When iPhone is attached (This has more specifics around the device, and potentially a different icon/image)
Alert User When Android is attached (Ditto above)
Alert User... (Potentially one for each of the supported devices)
Definitely try to avoid splitting across technical lines such as "Front end" and "Back End". It feels right at first due to our technical nature, but demos don't really have the same impact and your PO and Scrum Master won't really have as good of a measure of progress.
3) Task creation is something that your team needs to figure out. If you're running 2 week iterations and the team is not finding task breakdown useful, then I'd say don't do it. If the team feels as if it helps them break down the work necessary to create the story then, by all means, do it. Task creation for the sake of task creation doesn't make a whole lot of sense IMO.
Hope that helps!
Brandon
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
How can I make bruteforce password recovery software in delphi using with parallel computing technologies for md5 Algorithms!
Can someone tell me some advise?
Thanks
Parallel computing makes sense in today's day and age due to most of our CPUs having multiple cores.
However, your performance is not a one to one relationship with the number of threads. You'll most likely want just one or two threads per core.
You can use TThread class to create multiple threads in Delphi.
Indy has a MD5 hash function in the IdHashMessageDigest unit.
Make sure that you know the exact algorithm, including the use of any salt, before you attempt to reverse an MD5 hash through brute force.
If there was no salt used, I think there are probably rainbow tables available for MD5 on the web already, where you can just do a search.
You'll most likely want to try a dictionary attack prior to trying every possibility. There are many dictionaries available for download on the Internet, easily found on Google.
With more specific questions, we can give more specific answers.
Edit
To create a grid computing system, whereby you distribute the work to many computers, you'll need a central management server that doles out pieces of the work to the other computers. If the results aren't returned within a certain time threshold, then you put it back in the queue.
You'll need to build a simple framework where you can pass in a few parameters that represent a work load to each client, upon request. Perhaps it's a range of values to try.
The client should contact the server to receive a piece of work, and it always report back when it has finished the work, or perhaps immediately if it makes a hit.
If you have enough computers, consider each client building a local rainbow table for each possible salt, utilizing the storage from each client.
Example of work queue
Here's an example of a piece of work that would be sent as a parameter, and most likely stored in a database.
You want to attack the hash SLDFJIJ44adsf.
Here are the tables:
Hashes
----------------------------
TargetHash Answer
----------------------------
SLDFJIJ44adsf NULL
Work
----------------------------
TargetHash Type RangeBegin RangeEnd DateAssigned
----------------------------
SLDFJIJ44adsf Dictionary aardvark beaver 2011-12-16
SLDFJIJ44adsf Dictionary beavis zoology 2011-12-16
SLDFJIJ44adsf Brute aaaa ZZZZ 2011-12-16
SLDFJIJ44adsf Brute aaaaa MZZZZ 2011-12-16
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am sure there are many developers out here who have team spread across different time zones. What are some of the challenges people face and whats the best way to tackle them?
I currently work in a different time zone than the rest of my team. The biggest challenge is early in the morning and late in the afternoon when some of us haven't started work for the day or some have already left for the day.
It's just part of the work effort and we all respect each others valuable time. If it's something critical (and that's a relative term) then we just call the team member or page/text the whole team. If that happens then we all respond as needed. No big deal. Because of the respect factor, we know to only use this if necessary.
During the normal working day we just use the standard stuff like email, phone, and IM.
In all honesty, any company that has split development of a project across time zones is out of touch with the realities of engineering. The MBAs, in an attempt to save themselves a buck or two, foist upon their engineers the unenviable position of altering the schedules of their lives - leading to high stress, longer work hours, lower morale, and higher turnover. Quality suffers, ship dates suffer, feature lists suffer. The only increase you'll see in your project is the bug count.
You can have engineering projects split up like this if you don't have any need for low-latency communication between project units. In other words - if they are working on almost entirely independent segments of the system.
We have a team that is distributed or has to work across 3 or 4 different timezones. In the course of this we have faced several challenges primarily relating to communication.
Meetings are tough to arrange at a convenient time for all team members to attend, so there can sometimes be a need to have subsets of the team meeting, or to forego the team meeting approach for an individual update approach where one primary team member is responsible for a particular overseas team.
Another issue is work handover and communication. For example, we have a resource in India and if they have a problem that causes them to stop work, it can take 2 or 3 days out of their schedule if we don't respond quickly enough, all due to the time difference. Therefore, it is imperitive that we not only schedule diverse work to fill these delays but that we also respond to their queries in a timely manner. We often assign testing tasks to resources in this particular timezone as that is often an asynchronous task without an end.
In addition, you need to have a good change management system and code repository. The more asynchronous you can make the communication channels, the better, and this goes for information exchange as well (such as source and issue tracking).
There is no reason why you can't make distributed teams work, especially in the current age where we can work from almost anywhere as long as we have a link to the Internet. However, it's important to know where your bottlenecks are in a project and to ensure that work is distributed accordingly.
If you dont have a great process which has tuned exclusively for this kind of a scenario, then different time zone is going to kill your project deadline. Atleast one side should be very flexible to adjust their time for the meetings. But ofcourse that will eventually create frustrations among the team members.
Check out this SO thread which talks about Outsourcing and its practical issues, I think you will get some points from there too https://stackoverflow.com/questions/111948/outsourcing
Or Outsourcing Tag - https://stackoverflow.com/questions/tagged/outsourcing
We have these kinds of issues with support - we are using 3 commercial SDKs and the support teams are in distant time zones (8-10 hours difference). Moreover, not all work days overlap.
This fact had a big impact on my reverse engineering abilities :)
Plan, plan and plan some more. A few other things to note:
1) Be aware of local holidays if the team is in other locales, e.g. different countries may have different holidays. For example, some sects celebrate some Chrisian holidays 2 weeks later than most Christians,e.g. some orthodox sects I'm thinking.
2) Plan on meetings at a specific time that may be outside the normal work hours. This was particularly true when there was a 13 hour time difference between the rest of the team and myself.
3) Be aware of "Core hours" with the time change, e.g. if I'm on Pacific time and want to update something in New Jersey on Eastern time and I do it at 5pm Pacific time, that is 8 pm Eastern time and there may not be anyone there to notice the change or test it before the following morning which may mean some support person gets up at 4:30am Pacific time as in the East some have started to show up for work and go, "Huh? Why isn't this working like it did yesterday?"
There is also the other obvious things of being aware if there are various alphabets involved, e.g. Latin, Cyrillic, Arabic, etc. and this may affect how a computer interprets some text entered.