I am looking to have a similar style of the table in the picture. I just do not know the code would make it in this way.
I know how to make table, but I do not know how would I make them in this way.
There's no simple answer to this question since it would take quite some time to create this entire table, which is a large commitment :-) If you're committed to it, it's worthwhile to understand, but you may want to begin with what you know and build off of it. Is there a particular part of this table that you are struggling with? Can you give us an example of how far you've gotten that we can expand on?
Here are a couple useful references that could help you get started:
A bit more about tables
A more advanced approach with different packages
I'm sure there are many others. Once you get started, try posting where you get stuck. I hope this helps!
I'm trying to show the table while I'm doing querying so I can see what I'm doing, does anyone know how to show the table?
Another question is, does anyone who knows sql mind helping me with misc questions? I have lots of bits of questions that I would like to ask which may not be appropriate for forums.
If you have a Postico license you can have multiple tabs and windows open at the same time. I'm not sure if that answers all of your concerns, but I hope that helps.
I would first like to say I am totally oblivious to the programming world. That being said, I have what is probably a very simple question to answer. I have built a SurveyMonkey survey with a "ranking" type question. There are 14 items in this ranking so it is already a difficult question to digest. However, SurveyMonkey makes it even more difficult by re-ordering each answer choice after a ranking is picked. For example, lets say I have answers listed in the order A,B,C,D and I want to rank them 1,3,4,2. When I change the ranking of answer B to 3 it reorders the answers to A,C,B,D. I DON'T want this to happen, as I mentioned there are 14 items in the question and re-ordering the answers just makes it impossible. HELP!
No, there's no way to change the behavior of the ranking question. Its behavior is discussed in SurveyMonkey's help documents here: http://help.surveymonkey.com/articles/en_US/kb/Ranking-Question-is-Automatically-Ordering-Answers
The question type you're looking for is a matrix question with forced ranking: http://help.surveymonkey.com/articles/en_US/kb/Matrix-Question Look under the heading "Forced Ranking (one response per column)"
I was wondering if this approach using "observe" still is the recommended approach to achieve joins between two collections.
Meteor and DBRefs
Thanks,
Vindberg.
During the first meteor meetup I asked one of the core developers this very question. The answer was, unfortunately, yes. Using observe is currently the only way to achieve a join, however I was told a solution to this will be added prior to 1.0. I wish I had more information than that. Personally I think the lack of built-in joins is one of meteor's biggest missing features, but I don't see people making a lot of noise about it.
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 3 years ago.
Improve this question
Here's a scenario I'm sure you're all familiar with.
You have a fairly "hands off" customer, who really doesn't want to get too involved in the decision making despite your best efforts.
An experienced development team spend hours discussing the pros and cons of a particular approach to a problem and come up with an elegant solution which avoids the pitfalls of the more obvious approaches.
The customer casually mentions after a quick glance that they want it changed. They have no understanding of all the usability / consistency issues you were trying to avoid in your very carefully thought out approach.
Despite explanations, customer isn't interested, they just want it changed.
You sigh and do what they ask, knowing full well what will happen next...
3 weeks later, customer says it isn't working well this way, could you change it? You suggest again your original solution, and they seize on it with enthusiasm. They invariably seem to have had a form of selective amnesia and blocked out their role in messing this up in the first place.
I'm sure many of you have gone through this. The thing which gets me is always when we know the time and effort that reasonably bright and able people have put in to really understanding the problem and trying to come up with a good solution. The frustration comes in contrasting this with the knowledge that the customer's choice is made in 3 minutes in a casual glance (or worse, by their managers who often don't even know what the project is really about). The icing on the cake is that it's usually made very late in the day.
I know that the agile methodologies are designed to solve exactly this kind of problem, but it requires a level of customer buy in that certain types of customers (people spending other peoples money usually) are just not willing to give.
Anyone any clever insight into how you deal with this?
EDIT: Oops - by the way, I'm not talking about any current or recent customer in this. It's purely hypothetical...
Make your customer pay by the effort you are putting into designing and developing the solution to their problem.
The more you work, the more you get. The customer will have to pay for his mistakes.
Customer will eventually learn to appreciate your experience and insight in the programming field.
Niyaz is correct, unfortunately getting a customer buy-in is difficult until they have been burned like this once before.
Additionally describe to the customer the scenario above and state how much extra it would cost if you went three or four weeks down the line and had to rewrite it due to a change and then let them use the prototype. It may take a few days to put one together so they can see both options (theirs [the wrong way], and yours [the right way]). Remember they are paying you not only for your ability to program but also your experience and knowledge of the issues which crop up.
Whatever the decision the customer makes, ensure that you get it documented, update your risks register for the project with the risks that the chosen implementation will incurr and speak to the project manager (if its not you) about the mitigation plans for them.
I agree with Niyaz. However at the time the customer suggests the change you should work out what the impact of the change will be, and how likely that impact is to happen. Then ask whomever is responsible (it's not always that customer) for the deliverable if they approve the change.
Making the impact clear (more cost, lower reliability, longer delivery time etc) is very important to helping the customer to make a decision. It's very important to describe the impacts on the project or their business in a factual way, and assess how likely that impact is to occur. "Maybes" and "i feel" are very ignorable.
After that as long as the right people approve the change and as long as they pay for it.. well you did give them what they wanted :)
One thing we have done with some success in the past in these kinds of situations is to hand the issues over to the client.
"OK, you want to change it - this is
what will happen if you do that. These
are the issues involved. You have a
think about how you'd like it to work
and then get back to us".
This approach doesn't tend to yield good solutions (unsurprisingly) but does tend to let the client see that it's not a "gut feeling", wild stab in the dark kind of question.
And failing that, it usually makes them stop asking you to change it!
Usually a scenario like this is caused by 2 things. The ones that are supposed to give you the requirement specifications are either don't put their hearts into the project because they have no interest in it, or because they really have no idea what they want.
Agile programming is one of the best ways, but there are other ways to do this. Personally I usually use a classic waterfall method, so spiral and agile methods are out of the questions. But this doesn't mean that you can't use prototypes.
As a matter of fact, using a prototype would probably be the most helpful tool to use. Think about the iceberg effect. The secret is that People Who Aren't Programmers Do Not Understand This. http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg
"You know how an iceberg is 90% underwater? Well, most software is like that too -- there's a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers...." - Joel Spolsky
Generating the prototype takes time and effort but it is the most effective way to gather requirements. What my project team did was, the UI designer was the one that made the prototypes. If you give the users a prototype (at least a working interface of what the application is going to look and feel like) then you will get lots of criticism which can lead to desires and requirements. It can look like comments on YouTube but it's a start.
Second issue:
The customer casually mentions after a quick glance that they want it changed. They have no understanding of all the usability / consistency issues you were trying to avoid in your very carefully thought out approach.
Generate another prototype. The key here are results that the users would like to see instead of advice that they have to listen to.
But if all else fails you can always list the pros and cons of why you implemented the solution, whether or not the particular solution they like is not the one you insisted on. Make that part of the documentation as readable as possible. For example:
Problem:
The park is where all the good looking women jog to stay in shape. Johnny Bravo loves enjoying "mother nature's beauty", so he's lookin to blend in... you know... lookin all buff and do a little jogging while chasing tail.
Alternative Solutions:
1) Put on black suede shoes to look as stylish as you can.
2) Put on a pair of Nike's. Essential shoes for running. Try the latest styles.
Implemented Solution:
Black suede shoes were top choice because... well because hot mommies dig black suede shoes.
Or else, if they won't pay for the effort, just avoid putting that much resources into the solution of the problem, and just give them exactly what they've asked for and then think about it after the three weeks have passed.
Somewhat frustrating, yes, but that's the way it'll always be with that kind of customers. At least you won't be losing money.