Related
In a recent interview, I was asked about the level of Continuous Integration practiced in our company. When I started describing what we did, the interviewer interjected and asked me the level number - sounded something like CMM level to me. When I told him that I was not aware of any levels followed in my current company, he seemed displeased at my answer.
I am not able to find any such information online.
Can someone please throw some light?
I am afraid the interviewer was not competent at what he was asking. Such interviewers would ask you
Why are manhole covers round?
And they expect you to say something along the lines of safety. But they would completely disregard other valid answers, such as the ones described here
There are no strictly defined levels as such. Merely some bloggers shared their personal view on the topic. Does it really matter if you are on Level A, Stage 2, or Phase III based on their private classification? No it does not. Shall you be aware of such classification to do CI properly? No, you should not.
The actual number is irrelevant, what is relevant is the description of CI process.
I agree that it was a bad interview question but some people have been talking about a maturity model for Continuous Delivery (with 5 levels). For example, take a look at
http://www.infoq.com/articles/Continuous-Delivery-Maturity-Model
Presently in the industry maturity levels for Continuous Integration are sort of customized. Some companies have maximum levels of 6 while some companies like mine follow 5 levels.
Continuous Integration concept was envisaged at ThoughtWorks and if you go through this document on their website you'll see they too follow a model of 5 levels.
P.S - It indeed was a vague interview question.
It sounds like your interviewer was asking about CMMI (Capability Maturity Model Integration)]1.
The levels here have very specific meanings, and are used to indicate the level of process maturity within an organization or team. I've never actually worked anywhere that has cared about CMMI, but if you are applying to a company where this is used, or where their clients use this, it may be important to them.
It sounds to me like the interviewer wanted to know if you knew about this at all, and could explain about the different levels. However, as mentioned previously, knowing about Continuous Integration and why it is good for your project (and when it can be bad) is the important piece to pull out. Not whether you've memorized the Wikipedia page on CMMI.
This topic has many thread. But also I am posting another one. All the post may be a way to do a sentiment analysis, but I found no way.
I want to implement the doing ways of sentiment analysis. So I would request to show me a way. During my research, I found that this is used anyway. I guess Bayesian algorithm is used to calculate positive words and negative words and calculate the probability of the sentence being positive or negative using bag of words.
This is only for the words, I guess we have to do language processing too. So is there anyone who has more knowledge? If yes, can you guide me with some algorithms with their links for reference so that I can implement. Anything in particular that may help me in my analysis.
Also can you prefer me language that I can work with? Some says Java is comparably time consuming so they don't recommend Java to work with.
Any type of help is much appreciated.
First of all, sentiment analysis is done on various levels, such as document, sentence, phrase, and feature level. Which one are you working on? There are many different approaches to each of them. You can find a very good intro to this topic here. For machine-learning approaches, the most important element is feature engineering and it's not limited to bag of words. You can find many other useful features in different applications from the tutorial I linked. What language processing you need to do depends on what features you want to use. You may need POS-tagging if POS information is needed for your features for example.
For classifiers, you can try Support Vector Machines, Maximum Entropy, and Naive Bayes (probably as a baseline) and these are frequently used in the literature, about which you can also find a pretty comprehensive list in the link. The Mallet toolkit contains ME and NB, and if you use SVMlight, you can easily convert the feature formats to the Mallet format with a function. Of course there are many other implementations of these classifiers.
For rule-based methods, Pointwise Mutual Information is frequently used, and some kinds of scoring-based methods, etc.
Hope this helps.
For the text analyzing there is no language stronger than SNOBOL. In SNOBOL-4 the Fortran interpretator, for example, takes only 60 lines.
NLTK offers really good Algorithm for sentiment analysis. It is open source so you can have a look at the source code and check out the algorithm used. You can even download NLTK book which is free and has some good material on sentiment analysis.
Coming to your second point I dont think Java is that slow. I am myself coding in c++ for years but lately also started with java as if you see a lot of very popular open source softwares like lucene, solr, hadoop, neo4j are all written in java.
Can anyone direct me in the right direction?
Basically, I'm trying to analyze stock prices and see if I can spot any patterns. I'm using PHP and MySQL to do this. Where can I find sample algorithms like the ones used in MetaStock or thinkorswim? I know they are closed source, but are there any tutorials available for beginners?
Thank you,
P.S. I don't even know what to search for in google :(
A basic, educational algorithm to start with is a dual-crossover moving average. Simply chart fast (say, 5-day) and slow (say, 10-day) moving averages of a stock's closing price, and you have a weak predictor of when to buy long (fast line goes above slow) and sell short (slow line goes above the fast). After getting this working, you could implement exponential smoothing (see previously linked wiki article).
That would be a decent start. Take a look at other technical analysis techniques, but do keep in mind that this is quite a perilous method of trading.
Update: As for actually implementing this? You're a PHP programmer, so here is a charting library for PHP. This is the one I used a few years ago for this very project, and it worked out swimmingly. Maybe someone else can recommend a better one. If you need a free source of data, take a look at Yahoo! Finance's historical data. They dispense CSV files containing daily opening prices, closing prices, trading volume, etc. of virtually every indexed corporation.
Check out algorithms at investopedia and FM Labs has formulas for a lot of technical analysis indicators.
First you will need a solid math background : statistics in general, correlation analysis, linear algebra... If you really want to push it check out dimensional transposition. Then you will need solid basis in Data Mining. Associations can be useful if yo want to link strict numerical data with news headlines and other events.
One thing for sure you will most likely not find pre-digested algorithms out there that will make you rich...
I know someone who is trying just that... He is somewhat successful (meaning is is not loosing money and is making a bit) and making his own algorithms... I should mention he has a doctorate in Actuarial science.
Here are a few more links... hope they help out a bit
http://mathworld.wolfram.com/ActuarialScience.html
http://www.actuary.com/actuarial-science/
http://www.actuary.ca/
Best of luck to you
Save yourself time and use programs like NinjaTrader and Wealth-Lab. Both of them are great technical analysis platforms and accept C# as a programming language for defining your trading rules. Every possible technical indicator you can imagine is already included and if you need something more advanced you can always write your own indicator. You would also need a lot of data in order for your analysis to be statistically significant. For US stocks and ETFs, visit www.Kibot.com. We have good experience using their data.
Here's a pattern for ya
http://ddshankar.files.wordpress.com/2008/02/image001.jpg
I'd start with a good introduction to time series analysis and go from there. If you're interested in finding patterns then the interesting term is "1D-Pattern Matching". But for that you need nice features, so google for "Feature extraction in time series". Remember GiGo. So make sure you have error-free stock price data for a sufficiently long timeperiod before you start.
May I suggest that you do a little reading with respect to the Kalman filter? Wikipedia is a pretty good place to start:
http://en.wikipedia.org/wiki/Kalman_filter/
This should give you a little background on the problem of estimating and predicting the variables of some system (the stock market in this case).
But the stock market is not very well behaved so you may want to familiarize yourself with non linear extensions to the KF. Yes, the wikipedia entry has sections on the extended KF and the unscented KF, but here is an introduction that is just a little more in-depth:
http://cslu.cse.ogi.edu/nsel/ukf/
I suppose if anyone had ever tried this before then it would have been all over the news and very well known. So you may very well be on to something.
Use TradeStation
It is a platform that lets you write software to analyze historical stock data. You can even write programs that would trade the stock, and you can back test your program on historical data or run it real time through out the day.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How do you show your clients/employers that you understood their requirements?
What do you recommend to use? Use-Case diagrams? Flow-Charts? Data-Flow-Diagrams? Decision Trees?
I'm not really asking for a very detailed answer. Just something simple to help me communicate with the person who wrote the requirements and to see if both of you are on the same page.
I usually put together a PowerPoint deck fairly early in a project, giving a high-level overview of the project, along with some architectural diagrams (the simpler the better) and screen mockups/wireframes. Then I have a "kick-off" meeting for requirements review, and talk through the business problem and proposed solution.
I simply explain the requirements back in my own language, supplying my assumptions and adding in limitations.
The requirement may be "Button turns green when clicked"
I would ask "Ok, so when the user clicks on the button, the background color of the button turns green, but the text stays the same color?"
Basically prompting the person giving the requirements to explain how THEY envision it working.
My role has a lot of requirements gathering. The best way I find is a two pronged approach, talk through a PowerPoint presentation keeping it all simple and high level, and showing a Proof of Concept or a mock up. Walking and talking the customer through will see them responding with many "what if's" such as "Can I chance the colour?" this gives everyone a broad idea of what they are getting. If you can get something the users can touch and play with that works really well at uncovering the hidden what if.
Then, back this high level up with really detailed low level requirements. Spell out the dotted "i" and crossed "t". Get the users to read through and sign them before anything more than the POC is done. Generally word with a lot of screenshots works well.
Unless the users can bring you UML's and data flow charts, don't use them in anything the customer sees or signs. If it is signed by the customer and you had to regigg the back end to meet a "what if" you have to totally get everything resigned.
The final thing is to ensure that the customers can talk to you in their own words about their requirements and spell out what they are getting. One way to do this is to sit in on any middle management sell to higher management.
Don't try and bamboozle the customer, if they want something changed at the last minute, explain what the cost will be, in time and money, and ask them if this totally required. Doing this, will often stop people making trivial changes, and force them to think about why they want the change.
Requirements are getting what the customer needs from what they say they want.
Edit-
To the point about showing screenshots early- this sometimes requires a good PM to let the customer know the time scales and where everything is at. If the PM helps to set some decent time frames and expectations, the customers won't get excited. The good thing of POC and screenshots is people get an image of what it could be like and can often work that inside their minds.
If you want to avoid screenshots do a wire-frame look or use a whiteboard and 20 mins of drawing. Just remember to save the whiteboard as a photo before you whipe it.
Whiteboarding (and the good old OHP) can be a godsend to requirements gathering- developing a good clear style of drawing concepts can save hours in workshops.
Flow charts tend to confuse some non-technical people (ie clients), as well as data flow diagrams. Use Cases are good and understandable, as well as Business Requirement and Technical Requirement documentation, possible some sort of rough wireframe sketches.
It really depends wich requirements you're talking about.
Functionnal requirements? Maybe that UML is the rigth tool for. But I would prefer a test o test specifications
GUI requirements? Nothing beats a paper and a pencil.
Security requirements? By describing the limits of your security, you avoid unexpected deceptions.
Reliability requirements? Both testing mechannism, and software/hardware backup/recovery plan.
Other requirements: depends of your client.
But anyway, keep in mind, and explain to the client that requirement WILL change during the development phase and that it will always be a discussion and a compromise between cost and functionnality. Being honnest give more confidence to your customer.
I think that the best way to show that you really understand the client idea is to build prototypes.
By the way I was present in the last edition of the Requirements Engineering conference and in one of the workshops (MERE), Siemens was showing and interesting software based on composing a video of the client idea (it was for projects not limited to software) just to ensure that all the requirements are fully understood.
Any way, the thing is that some times a creative way to show them is better. Don't limit yourself to the standard diagrams.
I have had good experiences with creating a simple vocabulary, with terms from the domain and their meanings and relationships, and then go through it and make sure everybody agrees on everything.
Writing and discussing the vocabulary forces you to think, rather than just thinking that "we'll figure that out later".
It's no silver bullet, of course, and should be used along with other means such as a functional requirements specification and possibly a prototype.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
How do you test the usability of the user interfaces of your applications - be they web or desktop? Do you just throw it all together and then tweak it based on user experience once the application is live? Or do you pass it to a specific usability team for testing prior to release?
We are a small software house, but I am interested in the best practices of how to measure usability.
Any help appreciated.
I like Paul Buchheit's answer on this from startup school. The short version of what he said listen to your users. Listen does not mean obey your users. Take in the data filter out all the bad advice and iteratively clean up the site. Lather, rinse, repeat.
If you are a small shop you probably don't have a team of QA or Usability people or whatever to go through the site. Your users are going to be the ones that actually use the site though. Their feedback can be invaluable.
If something is too hard for one of your users to use or too complex to understand why they should use it, then it might be the same way for 1000 other users. Find a simpler way of accomplishing the same thing.
Once you have gathered all of this feedback and have a list of things to do, do the simplest ones first. That way you have forward moving usability progress.
What I like to do is give someone an install package, ask them to perform a number of tasks related to how the application works, and watch.
Hardest part is to keep your mouth shut.
Some of the best advice on usability testing is available on Jakob Nielsen's Website http://www.useit.com. He advocates what Will mentioned - ask users to perform various tasks on your website or web application and then sit back to see what they do.
Do not interrupt the users by asking questions or guiding them. Just observe them and document their flow. You can also get hardware and software to do eye-tracking and understand what captures the attention of the users.
However, usability should not start from the testing phase. You must have some general idea of what users generally like and do not like when you do development. There are many websites and books outlining generally accepted usability standards and principles.
Normally, we test the usability of new interfaces by asking a small selection of users to try out a beta version.
We give a small amount of instruction as to what the new features/screens are supposed to do and let them dive straight into it. It's very interesting to see where they are looking and clicking. We never demo the new features - we only talk about what it does.
If the UI changes are minimal then they go live and we gather feedback from real users. It's only when we are making big changes that we go through usability tests on beta.
When developing new screens it usually helps a hell of a lot to get a colleague sat in front of the UI and ask them what it does. Which areas do they click on? Where are they looking first? What sections are drawing their attention? etc.
I agree with Adam; using a very computer illiterate person is very helpful. However, what I've run into before with that is the program I want them to try out just isn't "up their alley" as far as something they would ever want to do.
A good way to start is with a paper prototype. Have specific tasks that you want your "user" to perform and have them do it. For more on paper prototyping, start here.
I frequently take any new interface I'm working on to one of our technical support people. They've heard every complaint about interfaces that you could ever imagine, so if anyone is going to think up potential problems, they will.
Also, and I'm not kidding about this, I often take the least computer literate person I know (you're mother is often a good choice...but they have to have used a computer before, otherwise it's going to by pointless) and let them loose on the interface with no instruction. If they can't figure out where things are intuitively, then your GUI likely needs work. Remember, Don't make them think! (yes, I know this is for web design, but it applies)
There are many ways to test the usability of a system. Please check any available literature you can find. I just want to insist that usability test is not so hard as you or anyone might think. In a famous paper called "A mathematical model of the finding of usability problems" in INTERACT'93 and CHI'93, J. Nielsen and T. K. Landauer showed that only five users are enough to find most problems in a small system.
If you have no way to read this paper, try this article in the author's website:
http://www.useit.com/alertbox/20000319.html
Z'been a while since this question was last active but here goes anyways.
From experience :
Always use Objectively measurable to decide if usability is better or not (time to accomplish carefully selected task, inactive time, KLM type metrics) here a key-mouse logger can be a precious ally
Never go too far ahead before consulting and measuring again with your client (do not encage yourself with the paper prototype and emerge with the finish product... that just never works)
read, read, read, try, evolve
Keep things simple and always remember the task at had (why the user needs the interface)
test, test and test again...
Always go to the bottom of the user requests. Although the check box the user request at this particular place may be the best thing to do, it almost always hides a more fundamental flaw
the system user (the one using it... as opposed to the one paying for it) is your best ally, keep him/her on your side
Never be afraid of refactoring your design and evolve your system. Also evolve your metrics and measurements also, however be careful in doing so not to break measurements continuity as it is the best token of objective progress in a VERY subjective world.
recommended reading (other than previously proposed):
Handbook of usability testing Jeff Rubin. A bit extreme but we toyed around an agile version of his approach and found that if we spent 30 minutes a week with users we would get a LOT of useful feedback while not getting swamped with too much info.
keep close watch to the Sneiderman and Nielsen of this world and other that may arrise
As usability inspection goes, there are several viable methods. They require a different amount of resources in regards to persons, analysis and equiptment.
The most common, and easiest to perform is called
Heuristic Evaluation
You basically walk through each screen to check if it conforms to the heuristics set by you, or your customer.
Check this article by Nielsen
Cognitive walkthrough
This method requires you to ask the user to complete steps in the application. You prepare steps for the user to complete. Issues that arrise during this walkthrough is taken into consideration when finishing the application.
Check this paper for details.
Think Aloud Analysis
I have used this method mostly in the early stages of prototyping. I let the user talk freely about the system while it is beeing used. Ask questions about use, design etc. You can get a really nice veiw of the general feeligns of the system, and what features are lacking.
Check this paper for details.
Interaction analysis
This is a more tricky one. I have only used the datagathering teqchniques proposed by this one. This technique takes into account context, activites, body language etc. Interaction analysis is commonly focused on research, not so much in commercial evaluations.
This link takes you to the article.
Keep in mind that these methods take practice to perfect. I would start with HE, continue to CW and THA. And only use Interaction Analysis if you have lots of resources and time.
There are a number of methods to test or evaluate usability of an application. Broken down into qualitative and quantitative methods and based on when you are planning to test.
Further it is categorized based on whether users are involved or experts do the testing.
To name a few methods,
Expert Reviews - user interface or usability experts rate the usability of an interface based on decided heuristics and principles
Formative usability testing - task flows are taken and users are provided with tasks to be completed. Qualitative feedback is collected based on what the users feel the pain points are during the testing. This form of testing is done during the design to provided feedback into the design of the application.
Summative Usability testing - task flows are taken and users are provided with tasks to be completed. The applications performance on efficiency, effectiveness and satisfaction are measured based on users completion of tasks.
The importance difference is whether you engage the user or a expert to tell you the difference in usability. Further on when you do the evaluation - at the end of the project or during the design phases.
I'm a strong believer in what I call 3-martini usability testing. When designing a system, imagine that the person who will be using it has just had 3 martinis.
Before handing over the system to colleagues (other programmers, quality assurance, tech support) or usability testers, an informal test with a couple of friends and a bottle of vodka (outside of work, of course) can often prove instructive.