Related
Pardon if this question is not appropriate. It is kind of specific and I am not asking for actual code but moreso guidance on whether or not this task is worth undertaking. If this is not the place, please close the question and kindly point me in the correct direction.
Short background: I have always been interested in tinkering. I used to play with partitions and OS X scripts when I was younger, eventually reaching basic-level "general programming" aptitude before my father prohibited my computer usage. I am now going to law school and working at a law firm but I love development and I want to implement more tech innovation in the field.
Main point: At our firm, we have a busy season every year from mid march to the first week of april (immigration + H1B deadline). We receive a lot of documents and scanned files that need to be verified, organized, and checked.
I added (very) simple lines of code to our online platform to help in organization; basically, I attached tags to all incoming documents, and once they were verified, the code would organize them by tag (like "identification doc", "work experience doc" etc.). This would my life much easier every year, as I end up working 100+ hour weeks this season.
I want to take this many steps further with an algorithm that can check for signatures and data mismatches between documents and ultimately organize the documents so they are ready to print. Eventually, I would like to maybe even implement machine learning and a very basic neural network to automate the whole mind-numbing and painful process...
Actual Question(s): I just wanted to know the best way for me to proceed or get started. I know a decent amount of python and java, and we have an online platform already with the documents. What other resources would you recommend in terms of books, videos, or even classes? Is there a name for this kind of basic categorization? Can I build something like this through my own effort without an advanced degree?
Stupid and over-dramatic epilogue: Truth be told, a part of me feels like I wasted my life thus far by not pursuing what I knew I loved at the age of 12. This is my way of making amends I guess, and if I can do this then maybe I can keep doing it in law and beyond...
You don't give many specifics about the task but if you have a finite number of forms in digital form as images, then this seems very possible.
I have personally used OpenCV with Python a lot and more complex machine learning tasks have become increasingly simple in the past 10 years.
Take for example object detection (e.g. 1, 2) to check whether there is anything in a signature field or try extracting the date from an image (e.g 1, 2).
I would suggest you start with the simplest thing that would improve your work. A small and easy task will let you build up your knowledge on how to do things.
I was wondering if someone could tell me what area/iteration in Team Foundation Server WorkItems is and how it should be used with projects?
Is it as simple as:
Area = Project Collection?
Iteration = Version Number?
I can't seem to find much information on what these are and what they are used for?
The short answer is that the area classification is the logical division of your product or project, and the iteration classification is its chronological breakdown into releases and development iterations.
The area path describes the logical part of the system that your work item relates to, e. g., which module or subsystem some bug was found in.
Likewise, the iteration path tells you which iteration put release a work item should be handled in, for example, this task is for the third iteration of the fifth release.
The logical and chronological breakdowns can be done any way that makes sense to your team, as long add the structure remains that of a tree.
Does this help?
Assaf.
The application and usage of areas and iterations seems to be a difficult choice for quite a few (myself included). There is of course also the consideration that you might want to have one or two physical "TFS projects" and place all your projects under that separated by areas and a larger hierarchical structure.
This blog post has some intersting questions and answers showing pros and cons on the matter:
http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
One cool explanation that stuck with me is this one "think of Areas as slicing and dicing a team project by “functionality” (like UI, Business Layer, DAL etc), and think of Iterations as slicing and dicing by “time”. Iterations are like “phases” of a lifecycle, which can dissect the timeline of a project effort into more manageable time-based pieces."
I would like to design a Inventory system. Some key features listed below.
Multi User
Multi Branch
Support Online and offline Invoicing
Multi Currency
Language requirements : -
C# 2.0
SQL2005 Server
I appreciate your valuable suggestions and ideas to design perfect Inventory system.
If you have any Database sample model to design such a system please don't hesitate to inform me.
Thanks.
You have some of your requirements listed here, but you do not have enough information to complete a design of an invoicing system, plus you have an unrealistic goal of a perfect inventory system - what is perfect for one person is imperfect for another; I'd settle for aiming for best of breed if I were you.
Do you have access to your customers? If you do, you need to sit down with them and find out what they want. A good way to do this is to model their working processes. Write down what steps they do from start to finish, and what influences their work (known as external actors or interfaces). This is a long process, but will end up with you being able to state exactly what is done, when, and in what order, plus the functional and non-functional constraints on the system.
Once you have this information, actually designing the physical system is relatively straightforward. Good luck.
[Big hint] The process I have described here makes heavy use of UML.[/Big hint]
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 2 years ago.
Improve this question
I have read a lot of articles on Dependency Injection as well as watched a lot of videos, but I still can't get my head around it. Does anyone have a good analogy to explain it?
I watched the first part of the Autumn of Agile screencast and still was a little confused.
Analogy? I'll give it a whack... Your CD Player stereo is useless without a CD with music on it... (It's dependent on the CD). If they built CD Players with the CD already in it, it would get boring very quickly...
So they build them so you can "inject" the CD, (on which it is dependent) into the player. That way you can inject a different one each time, and get "different" behavior (music) dependent on which one you inject.
The only requirement is that the CD must be compatible with the interface defined by the player. (You can't play a blue-ray disk in a 1992 CD player.)
The best analogy I can think of is that of hiring a mechanic.
Without dependency injection, you hire a mechanic and the mechanic brings his own tools. He may have lousy tools, he may have great tools, he may be using a pipe wrench when he should be using a socket. You don't know, and may not care, so long as he gets the work done.
With dependency injection, you hire a mechanic and you provide him with the tools that you want him to do his work with. You get to choose what you consider to be the best or most appropriate tools for the work you are hiring him to do.
Think of it as a realisation of the "Inversion of Control" pattern. I guess, your problem is, you are so used to it, you don't realize it's that simple.
Let's start at the beginning.
In the early days programs followed a given path through the code. The order of the called functions was given by the programmer.
In interactive programs, e.g. mostly ANY program, you can not say, which function is called at what time. Just look at a GUI or website. You can not say, at what time what button or link is clicked. So the "control" of what's happening is no longer at the program, it's at an outer source. The "control" has been inverted. The function is no longer "acting" it is instead "listening". Think of the hollywood principle: "Don't call us, we call you". A listener is a good example for a realisation of this pattern.
IoC is realized by functions or "methods" in the "object oriented world" of today.
"Dependency Injection" now means the same, but not for "methods", which do something, but for "objects", which hold data.
The data is no longer part of the object holding it. It is "injected" into the object at runtime. To stay in hollywood, think of a film star, playing golf to talk about the business, but to keep in shape, she hungers herself down, minimizing her muscle weight and therefore she is only able to carry one club at a time.
So, on the golf course her game would heavily depend on the one club, she is carrying.
Lucky for her, there are caddies, carrying a whole lot of clubs at one time, and also having the knowledge what club to use at what time. Now she is independent of her limited possibility to carry golf clubs. "Don't think about a concrete club to wear, we know them all and give you the right one at the right time".
The film star is the object and the golf clubs are the members of the object. That's dependency injection.
Maybe focus on the "injection" part? When I see that term, I think of syringes. The process of pushing the dependencies of a component to the component can be thought of as injecting into the component.
Just like with the body, when there is something that it needs in the way of medicine (a component that it needs) you can inject it into the body.
In their 2003 JavaPolis presentation (slides), Jon Tirsén & Aslak Hellesøy had an amusing analogy with a Girl object that needs a Boy to kiss. I seem to remember that the BoyFactory is sometimes known as a 'nightclub', but that's not in the slides.
Another analogy: let us say you are a developer and whenever you like you order computer science books from the market directly - you know the sellers and their prices. In fact your company might have a preferred seller and you contact them directly. All this works fine but may be a new seller is now offering better prices and your company wants to change the 'preferred' seller.
At this point you have to make the following changes - update the contact details (and other stuff) so as to use the new seller. You still place the order directly.
Now consider we introduce a new step in between, there is a 'library' officer in the company and you have to go through him to get the books. While there is a new dependency, you are now immune to any changes to the seller: either the seller changes mode of payment or the seller himself is changed, you now simply put an order to the librarian and he gets the books for you.
From Head First Design Patterns:
Remember, code should be closed (to change) like the lotus flower in the evening, yet open (to extension) like the lotus flower in the morning
A DI-enabled object can be configured by injecting behaviors defined in other classes. The original object structure doesn't have change in order to create many variations. The injection can be made explicit by having a class request other worker-classes in its constructor, or it can be less obvious when using monkeypatching in dynamic languages like Python.
Using an analogy of a Person class, you can take a basic human framework, pass it a set of organs, and watch it evolve. The Person doesn't directly know how the organs work, but their behaviors confirm to an expected interface and influence the owner's physical and mental manifestation.
A magician's sleight of hand! What you may think you see may be secretly manipulated or replaced.
Life is full of dependency injection analogies:
printer - cartridge
digital device - battery
letter - stamp
musician - instrument
bus - driver
sickness - pill
The essence of Inversion of Control (of which Dependency Injection is an implementation) is the separation of the use of an object from the management thereof.
The analogy/example I use is an engine. An engine requires fuel to run, i.e. it is depdendent on fuel. However, the engine cannot be responsible for the fuel it needs. It just 'asks' for fuel, and it is provided (typically by a fuel pump in a car).
The analogy starts breaking down when you look too deep, in that an engine doesn't ask for fuel, it is given it by some kind of management element, like an ECU. One might be able to compare the ECU to a container but I'm not certain how valid this is.
Your project manager asks you to write an app.
You could just write some code based on your career experience so far, but it's unlikely to be what your PM wants.
Better would be if your PM dependency injected you with say a spec for the app. Now your code is going to be related to the spec he gives you.
Better if you were told where the source repository was.
Better if you were told what the tech platform was.
Better if you were told when this needed to be done by.
Etc..
I think a great analogy is a six-year-old with a lego set.
You want your objects to be like the lego bricks. Each one is independent of all the others, and yet offers a clear interface for connecting them to the others. When connecting them together, it doesn't really matter exactly which two bricks you hook together so long as they have a matching interface.
Your dependency injection framework is like the six-year-old. He follows the instructions (i.e., your config file, annotations, etc.) to connect specific bricks together in certain ways to make a particular model.
Of course, since the bricks' interfaces are pretty generalized, they can go together in lots of different ways, so it's easy to come up with new sets of instructions which the six-year-old can use to make a completely different model out of the same bricks.
I've encountered the term "multi-agent computing" as of late, and I don't quite get what it is. I've read a book about it, but that didn't answer the fundamental question of what an agent was.
Does someone out there have a pointer to some reference which is clear and concise and answers the question without a load of bullshit/marketing speak? I want to know if this is something I should familiarise myself, or whether it's some crap I can probably ignore, because I honestly can't tell.
In simple terms, multiagent research tries to design system composed of autonomous agents. That is, you have a bunch of robots/people/software-agents around, each of which can take its own actions but can only "see" stuff that is around him, how do get the system to behave as you want?
Example,
Given a bunch of robots with limited sensing capabilities, how do you get them to monitor a field for enemies? to find all the mines in a field?
Given a bunch of people, how do you get them to maximize the happiness of the least happy person? without taking away their freedom.
Given a group of people, how do you set up a meeting time(s) that maximizes their happiness? without revealing their private information?
Some of these questions might appear really easy to solve, but they are not.
Multiagent research mixes techniques from game theory, Economics, artificial intelligence, and sometimes even Biology in order to answer these questions.
If you want more details, I have a free textbook that I am working on called Fundamentals of Multiagent Systems.
A multi-agent system is a concept borrowed from AI. It's almost like a virtual world where you have agents that are able to observe, communicate, and react. To give an example, you might have a memory allocation agent that you have to ask for memory and it decides whether or not to give it to you. Or you might have an agent that monitors a web server and restarts it if it hangs. The main goal behind multiagent systems is to have a more Smalltalk-like communication system between different parts of the system in order to get everything to work together, as opposed to more top-down directives that come from a central program.
"Agents" are another abstraction in software design.
As a crude hierarchy;
Machine code, assembly, machine-independent languages, sub-routines, procedures, abstract data types, objects, and finally agents.
As interconnection and distribution become more important in computing, the need for systems that can co-operate and reach agreements with other systems (with different interests) becomes apparent; this is where agents come in. Acting independently agents represent your best interests in their environment.
Other examples of agents:
Space craft control, to make quick decisions when there's no time for craft-ground crew-craft messaging (eg NASA's Deep Space 1)
Air traffic control (Systems over-riding pilots; this is in place in most commercial flights, and has saved lives)
Multi-agent systems are related to;
Economics
Game theory
Logic
Philosophy
Social sciences
I don't think agents are something you should gloss over. There's 2 million hits on google scholar for "multi agent" and more on CiteSeer; it's a rapidly evolving branch of computer science.
There are several key aspects to multi-agent computing, distribution and independence are among them.
Multi-agents don't have to be on different machines, they could as #Kyle says, be multiple processes on a single chip or machine, but they act without explicit centralised direction. They might act in concert, so they have certain synchronisation rules - doing their jobs separately before coming together to compare results, for example.
Generally though the reasoning behind the segmentation into separate agents is to allow for differing priorities to guide each agent's actions and reactions. Perhaps using an economic model to divide up common resources or because the different functions are physically separated so don't need to interact tightly with each other.
<sweeping generalisation>
Is it something to ignore? Well it's not really anything in particular so it's a little like "can I ignore the concept of quicksort?" If you don't understand what quicksort is then you're not going to fail to be a developer because most of your life will be totally unaffected. If you have more understanding of different architectures and models, you'll have more knowledge to deploy in new and unpredictable places.
<sweeping generalisation>
Ten years ago, 'multi-agent systems' (MAS) was one of those phrases that appeared everywhere in the academic literature. These days it is less prevalent, but some of the ideas it represents are really useful in some places. But totally unnecessary in others. So I hope that's clear ;)
It is difficult to say what multi-agent computing is, because the definition of an agent is usually very soft surrounded by markting terms etc. I'll try to explain what is it and where it could be used based on the research of manufacturing systems, which is the area, I am familiar with.
One of the "unsolved" problems of modern manufacturing is scheduling. When the definition of the problem is static, an optimal solution can be found, but in reality, people don't come to work, manufacturing resources fail, computers fail etc. The demand is changing all the time, different products are required (i.e. mass customization of the product - one produced car has air conditioning, the next one doesn't, ...). This all leads to the conclusions that a) manufacturing is very complex, b) static approaches, like scheduling in advance for a week, don't work. So the idea is this: why wouldn't we have intelligent programs representing parts of the systems, working the way out of this mess on their own? These programs are called agents. They should communicate and negotiate amongst themselves and make sure the tasks are done in due time. By using agents we want to lower the complexity of the control system, make it more manageable, enable better human - machine interaction, make it more robust and less error prone and very importantly: make the control system decentralized.
In short: agents are just a concept, but they are a concept everyone can intuitively understand. Code still needs to be written, but it is written in a different way, one abstraction higher than OOP.
There was a time when it was hard to find good material on software agents, primarily because of the perception of marketing potential. The bloom on that rose has diminished so the signal to noise ratio on the Internet has improved vis-a-vie software agents.
Here is a good introduction to software agents on this blog post of an open source project for software agents. The term multi-agent systems just means a system where multiple software agents run and communicate and delegate sub tasks to each other.
According to Jennings and Wooldridge who are 2 of the top Mulit-agent researchers an agent is an object that is reactive to its environment, proactive and social. That is an agent is a piece of software that can react to its environment in real time in a way that is suitable to its own objeective. It is proactive, which means that it doesnt just always wait to be asked to perform a task, if it sees a chance to do something that it feels would be beneficial to its objectives it does it. And that it is social, ie that it can communicate with other Agents, doesnt nessecaily ever have to do any of these things in meeting its own objectives but it should be able to to do these if the situation arose. And thus a multi-agent system is just a collection of these in a distrubuted system that can all communicate and try to perform their own personal goals hat normally lead to an overall achievement of the system goal.
You can find a concentration of white papers concerning agents here.