How to parse json file in flutter? - json

Below is the json I have to parse.
[
"http://activepeersai.computing.dcu.ie/feedback_participant/114",
"http://activepeersai.computing.dcu.ie/peerLearningPrompter/4",
"{\"0\":{\"feedback_id\":114,\"timer_used\":1,\"timer\":10.0,\"question1\":\"How to break ice with strangers (in social gathering & in formal events) ?\",\"question2\":\"How to build networking (with those from different age, culture, education background, language\\u2026)(in university & in workplace) ?\",\"question3\":\"\",\"question4\":\"\",\"question5\":\"\",\"question6\":\"\",\"question7\":\"\",\"question8\":\"\",\"question9\":\"\",\"question10\":\"\"},\"1\":{\"feedback_id\":115,\"timer_used\":1,\"timer\":10.0,\"question1\":\"How to deal with difficult teammates (dominating \\/ debater character \\/ negative \\/ lack of confidence \\/ free rider\\u2026) ?\",\"question2\":\"How to build mutual trust with teammates ?\",\"question3\":\"\",\"question4\":\"\",\"question5\":\"\",\"question6\":\"\",\"question7\":\"\",\"question8\":\"\",\"question9\":\"\",\"question10\":\"\"}}",
"{\"id\":{\"0\":1,\"1\":2,\"2\":3,\"3\":4,\"4\":5,\"5\":6,\"6\":7,\"7\":8,\"8\":9,\"9\":10,\"10\":11,\"11\":12,\"12\":13,\"13\":14,\"14\":15,\"15\":16,\"16\":17,\"17\":18,\"18\":19,\"19\":20,\"20\":21,\"21\":22,\"22\":23,\"23\":24,\"24\":25,\"25\":26,\"26\":27,\"27\":28,\"28\":29,\"29\":30,\"30\":31,\"31\":32,\"32\":33,\"33\":34,\"34\":35,\"35\":40,\"36\":41,\"37\":42,\"38\":43,\"39\":44,\"40\":45,\"41\":46,\"42\":47,\"43\":48,\"44\":49,\"45\":50,\"46\":51,\"47\":52,\"48\":53,\"49\":54,\"50\":55,\"51\":56,\"52\":57,\"53\":58,\"54\":59,\"55\":60,\"56\":61,\"57\":62,\"58\":63,\"59\":36,\"60\":37,\"61\":38,\"62\":39},\"name\":{\"0\":\"Why did the sharer choose this skill as the most confident skill and why did the learner wants to improve this skill?\",\"1\":\"Can you share another situation whereby using this skill made a very big difference to the outcome? What did you do? What was the result? What might have happened if this skill wasn't brought to the situation?\",\"2\":\"What advice do you have to give to others about becoming better at using this skill in their work and in their lives generally?\",\"3\":\"What can hold people back from being better at this skill? How can you encourage them to overcome these challenges?\",\"4\":\"What would be the outcome if this session\\/series was a huge success? How would we know if this happened?\",\"5\":\"What is working for you now? What is stopping you from moving forward?\",\"6\":\"What do your role models do that you would love to learn\\/incorporate as habits\\/adopt as a mindset?\",\"7\":\"\\\"What got you here won't get you there.\\\" What is your reaction to that statement? What actions have got you to this point that may not serve you if you move forward? What new behaviours do you need to adopt?\",\"8\":\"What would be the outcome if this session\\/series was a huge success? How would we know if this happened?\",\"9\":\"If you had all the time, people, money, resources that you might possibly need, what would you do differently? Does that energise you, frighten you or a bit of both?\",\"10\":\"What do you think you need to do get a better result (or closer to your goal)?\",\"11\":\"What is the worst that could happen and how could you handle it? What is the best that could happen and how could you handle it?\",\"12\":\"What have been the most impactful decisions that you've made in your career? What led to making those decisions? Were you aware of the impact those decisions would have? What would you say to others in a similar position?\",\"13\":\"What habits have stood you in good stead? Are there things that you do regularly, daily or very often that have made a big different over time?\",\"14\":\"Can you share an experience that was transformational for you, taught you a long-lasting lesson or was particularly memorable for its benefits and challenges?\",\"15\":\"How do you think experience affects somebody's perspective, way of making decisions or their feelings about taking risks?\",\"16\":\"Can you describe your target market for your business or who might your ideal employer be?\",\"17\":\"Can you share details of a project that you worked on recently? Why were you or your business chosen to work with this client\\/employer? What were the success and challenges along the way?\",\"18\":\"What makes you\\/your product\\/your service different to others? Why would a client or employer choose what you do over others?\",\"19\":\"What might I be able to do to help you?\",\"20\":\"What is the key problem that you are facing currently?\",\"21\":\"If that problem was solved, what impact would it have?\",\"22\":\"In order to get to that outcome, what do we need to do, what resources need to be invested and any other changes to be made?\",\"23\":\"Is there a willingness to take that action to get towards that outcome?\",\"24\":\"What assumptions are being made? How likely are each one to happen? What would be the impact of those assumptions happening or not happening?\",\"25\":\"What application of the SCAMPER technique could be useful to help get another perspective?\\n*SCAMPER is an acronym formed from the abbreviation of: Substitute, Combine, Adapt, Modify (Also magnify and minify), Put to another use, Eliminate and Reverse.\",\"26\":\"If we had double the budget, half the time and were living in another country trying to make this happen, how might we think differently?\",\"27\":\"If any idea generated already in this discussion was to become a reality, what would be the impact on e year later in terms of benefits, ongoing coasts, sustained behavioural change and a launchpad for further growth?\",\"28\":\"Leadership\",\"29\":\"Communication\",\"30\":\"Adaptability\",\"31\":\"Team Work\",\"32\":\"Problem Solving\",\"33\":\"Conflict Management\",\"34\":\"Productivity\",\"35\":\"How would you describe good\\/effective communication? Please share an example of a time that you've seen it in action and an example of when you saw that good communication skills were clearly lacking.\",\"36\":\"How have you handled working under someone you felt was not good at communicating?\",\"37\":\"If you're trying to get your point across or convince somebody that your idea is the right one, what do you do?\",\"38\":\"Who do you think is a good communicator and why? What can we learn from them?\",\"39\":\"Talk about a time that you needed to adapt to a new situation. What did you find difficult and how did you work through that? How can somebody prepare to be more adaptable in future situations?\",\"40\":\"When you're in a situation where it feels like you have no control over it (i.e. a new manager, starting in a new job, government-led changes etc), what do you do to focus on what you can do?\",\"41\":\"How do you handle having multiple priorities at the same time?\",\"42\":\"How do you adjust to different work settings? For example, working with different teams, switching between logic and creativity, learning new processes, tools or technologies?\",\"43\":\"How do you feel about working in a team? What do you think are the key things that need to happen to make good teamwork?\",\"44\":\"What has been your experience of working in teams where there were problems? Did these arise due to strong personalities, somebody not sharing the workload, miscommunication, the wrong support or technology systems etc?\",\"45\":\"How do you keep a team motivated? Share your story about a rewarding team experience.\",\"46\":\"When you're in a team situation, what role do you usually play?\",\"47\":\"Describe a situation where you had to solve a problem. What did you do? what was the result? What might you have done differently?\",\"48\":\"What steps do you take before making a decision on how to solve a problem, and why?\",\"49\":\"Give an example of a situation in which you saw an opportunity in a potential problem. What did you do? What was the outcome?\",\"50\":\"Can you tell me about a situation where you overcame a problem using a creative solution?\",\"51\":\"Have you ever had a team member who kept raising objections on projects? How did you (or would you) manage them?\",\"52\":\"You have noticed that a team member is aggressive or arrogant toward the rest of the team. How would you approach this person?\",\"53\":\"What would you do if your manager gave you negative feedback on the way you approached a problem? How do give negative\\/constructive feedback to others?\",\"54\":\"How could you use a situation with conflict to have a better relationship with all involved?\",\"55\":\"How would you describe a typical working day in your current role? How you manage importance versus urgency? How do you maintain a work-life balance also?\",\"56\":\"If you have your day planned out to achieve a goal, how do you manage distractions or other things that can happen along the way?\",\"57\":\"What do you think very productive people do differently than others?\",\"58\":\"What holds people back from being more productive? How can people turn those around so that by doing the opposite, they can become more productive?\",\"59\":\"Have you ever had a team member who kept raising objections on projects? How did you (or would you) manage them?\",\"60\":\"How do you describe your leadership style?\",\"61\":\"What was a difficult decision you had to make as a leader, and how did you come to that decision?\",\"62\":\"What are the most important attributes of successful leaders today? Who do you think is a good leader and why?\"},\"session_type_id\":{\"0\":1.0,\"1\":1.0,\"2\":1.0,\"3\":1.0,\"4\":2.0,\"5\":2.0,\"6\":2.0,\"7\":2.0,\"8\":3.0,\"9\":3.0,\"10\":3.0,\"11\":3.0,\"12\":4.0,\"13\":4.0,\"14\":4.0,\"15\":4.0,\"16\":5.0,\"17\":5.0,\"18\":5.0,\"19\":5.0,\"20\":6.0,\"21\":6.0,\"22\":6.0,\"23\":6.0,\"24\":7.0,\"25\":7.0,\"26\":7.0,\"27\":7.0,\"28\":8.0,\"29\":8.0,\"30\":8.0,\"31\":8.0,\"32\":8.0,\"33\":8.0,\"34\":8.0,\"35\":null,\"36\":null,\"37\":null,\"38\":null,\"39\":null,\"40\":null,\"41\":null,\"42\":null,\"43\":null,\"44\":null,\"45\":null,\"46\":null,\"47\":null,\"48\":null,\"49\":null,\"50\":null,\"51\":null,\"52\":null,\"53\":null,\"54\":null,\"55\":null,\"56\":null,\"57\":null,\"58\":null,\"59\":null,\"60\":null,\"61\":null,\"62\":null},\"session_type_name\":{\"0\":\"Learning and Development\",\"1\":\"Learning and Development\",\"2\":\"Learning and Development\",\"3\":\"Learning and Development\",\"4\":\"Mentoring\",\"5\":\"Mentoring\",\"6\":\"Mentoring\",\"7\":\"Mentoring\",\"8\":\"Coaching\",\"9\":\"Coaching\",\"10\":\"Coaching\",\"11\":\"Coaching\",\"12\":\"Experience Sharing\",\"13\":\"Experience Sharing\",\"14\":\"Experience Sharing\",\"15\":\"Experience Sharing\",\"16\":\"Networking\",\"17\":\"Networking\",\"18\":\"Networking\",\"19\":\"Networking\",\"20\":\"Establishing Buy-In\",\"21\":\"Establishing Buy-In\",\"22\":\"Establishing Buy-In\",\"23\":\"Establishing Buy-In\",\"24\":\"Idea Exploration\",\"25\":\"Idea Exploration\",\"26\":\"Idea Exploration\",\"27\":\"Idea Exploration\",\"28\":\"Seven Soft Skills\",\"29\":\"Seven Soft Skills\",\"30\":\"Seven Soft Skills\",\"31\":\"Seven Soft Skills\",\"32\":\"Seven Soft Skills\",\"33\":\"Seven Soft Skills\",\"34\":\"Seven Soft Skills\",\"35\":null,\"36\":null,\"37\":null,\"38\":null,\"39\":null,\"40\":null,\"41\":null,\"42\":null,\"43\":null,\"44\":null,\"45\":null,\"46\":null,\"47\":null,\"48\":null,\"49\":null,\"50\":null,\"51\":null,\"52\":null,\"53\":null,\"54\":null,\"55\":null,\"56\":null,\"57\":null,\"58\":null,\"59\":null,\"60\":null,\"61\":null,\"62\":null},\"parent_id\":{\"0\":null,\"1\":null,\"2\":null,\"3\":null,\"4\":null,\"5\":null,\"6\":null,\"7\":null,\"8\":null,\"9\":null,\"10\":null,\"11\":null,\"12\":null,\"13\":null,\"14\":null,\"15\":null,\"16\":null,\"17\":null,\"18\":null,\"19\":null,\"20\":null,\"21\":null,\"22\":null,\"23\":null,\"24\":null,\"25\":null,\"26\":null,\"27\":null,\"28\":null,\"29\":null,\"30\":null,\"31\":null,\"32\":null,\"33\":null,\"34\":null,\"35\":30.0,\"36\":30.0,\"37\":30.0,\"38\":30.0,\"39\":31.0,\"40\":31.0,\"41\":31.0,\"42\":31.0,\"43\":32.0,\"44\":32.0,\"45\":32.0,\"46\":32.0,\"47\":33.0,\"48\":33.0,\"49\":33.0,\"50\":33.0,\"51\":34.0,\"52\":34.0,\"53\":34.0,\"54\":34.0,\"55\":35.0,\"56\":35.0,\"57\":35.0,\"58\":35.0,\"59\":29.0,\"60\":29.0,\"61\":29.0,\"62\":29.0}}"
]
We can forget about the 4th line for now.
I'll tell you a bit about my app. The app can have 2 rounds, each round having a maximum of 10 questions, each question will have a timer for 3 minutes. Now I need to get these questions(3rd line) from this json and display in the app.
The below list is what I'll have to update.
import 'package:activepeers_app_internship/models/questions.dart';
List<Question> sample_data = [
Question(id: 1,
question: "Flutter is an open-source UI software development kit created by ______",
),
Question(
id: 2,
question: "When google release Flutter.",
),
Question(
id: 3,
question: "A memory location that holds a single letter or number.",
),
Question(
id: 4,
question: "What command do you use to output data to the screen?",
),
];
Can you tell me how to get those questions here as I don't know how to.

What you receive is JSON. It is an array of Strings. The third element is a String, which can be interpreted as JSON (JSON encoded as String). You can use jsonDecode to decode it to a Map<String, dynamic> – you then have to parse the map and initialize your model.
You can read it all in detail here:
https://docs.flutter.dev/development/data-and-backend/json
For example:
import 'dart:convert';
class User {
final String name;
final String email;
User(this.name, this.email);
User.fromJson(Map<String, dynamic> json)
: name = json['name'],
email = json['email'];
Map<String, dynamic> toJson() => {
'name': name,
'email': email,
};
}
void main() {
// in your example you would get read the string from the third line
// of the response
final jsonString = '{"name":"John Smith","email":"john#example.com"}';
Map<String, dynamic> userMap = jsonDecode(jsonString);
var user = User.fromJson(userMap);
print('Howdy, ${user.name}!');
print('We sent the verification link to ${user.email}.');
}

Related

The Implications of Modern Day Software Development Abstractions [closed]

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 6 years ago.
Improve this question
I am currently doing a dissertation about the implications or dangers that today's software development practices or teachings may have on the long term effects of programming.
Just to make it clear: I am not attacking the use abstractions in programming. Every programmer knows that abstractions are the bases for modularity.
What I want to investigate with this dissertation are the positive and negative effects abstractions can have in software development. As regards the positive, I am sure that I can find many sources that can confirm this. But what about the negative effects of abstractions? Do you have any stories to share that talk about when certain abstractions failed on you?
The main concern is that many programmers today are programming against abstractions without having the faintest idea of what the abstraction is doing under-the-covers. This may very well lead to bugs and bad design. So, in you're opinion, how important is it that programmers actually know what is going below the abstractions?
Taking a simple example from Joel's Back to Basics, C's strcat:
void strcat( char* dest, char* src )
{
while (*dest) dest++;
while (*dest++ = *src++);
}
The above function hosts the issue that if you are doing string concatenation, the function is always starting from the beginning of the dest pointer to find the null terminator character, whereas if you write the function as follows, you will return a pointer to where the concatenated string is, which in turn allows you to pass this new pointer to the concatenation function as the *dest parameter:
char* mystrcat( char* dest, char* src )
{
while (*dest) dest++;
while (*dest++ = *src++);
return --dest;
}
Now this is obviously a very simple as regards abstractions, but it is the same concept I shall be investigating.
Finally, what do you think about the issue that schools are preferring to teach Java instead of C and Lisp ?
Can you please give your opinions and your says as regards this subject?
Thank you for your time and I appreciate every comment.
First of all, abstractions are inevitable because they help us to deal with the mind-blowing complexity of things.
Abstractions are also inevitable because it is more and more required of an individual to undertake more tasks or even complete projects. To address the problem, one uses libraries which wrap lower-level concepts and expose more complex behavior.
Naturally, a developer has less and less time to know the intrinsics of the things. The latest concern I heard about on SO pages is starting to learn JavaScript with jQuery library, ignoring the raw JavaScript at all.
The issue is about the balance between:
Know the little tiniest details of some technology and be a master of it, but at the same time being unable to work with anything else.
Superficial knowledge of a wide variety of technologies and tools which however proves sufficient for common everyday tasks which allows an individual to perform in multiple areas possibly covering all sides of some (moderately big) project.
Take your pick.
Some work requires the one, another position requires the other.
So, in you're opinion, how important is it that programmers actually know what is going below the abstractions?
It would be nice if people knew what is happening behind the scenes. This knowledge comes with time and practice, up to a certain degree. Depends on what kind of tasks you have. You certainly shouldn't blame people for not knowing everything. If you wish a person to be able to perform in a variety of fields, it is inevitable he won't have time to cover each up to the last bit.
What is essential, is the knowledge of the basic building blocks. Data structures, algorithms, complexity. That should provide a basis for everything else.
Knowing tiniest details of some particular technology is good, but not essential. Anyway, you can't learn them all. They're too many and they keep coming.
Finally, what do you think about the issue that schools are preferring to teach Java instead of C and Lisp ?
Schools shouldn't be teaching programming languages at all. They're to teach basics of theoretical and practical CS, social skills, communication, team work. To cover a vast variety of topics and problems to provide a wide angle view for their graduates. This will help them to find their way. Whatever they need to know in details, they'll do it on their own.
An example where abstraction has failed:
In this case, a piece of software was needed to communicate to many different third party data processors. The communication was done through various messaging protocols; the transport method/protocol is not important in this case. Just assume everyone communicated through messaging.
The idea was to abstract the features of each of these third parties into a single, unified message format. It seemed relatively straightforward because each of the third parties performed a similar service. The problem was that some third parties used different terms to explain similar features. It was also found that some third parties had additional features that other third parties did not have.
The designers of the abstraction did not see through the difference of third party terms nor did they think it was reasonable to limit the scope of the unified features to only support the common features of the third parties. Instead, a single, monolithic message schema was developed to support any and all features of the third parties considered at the time. In what was probably considered a future-proofing move, they added a means of also passing an infinite number of name/value pairs along with the monolithic message in case there were future data elements that the monolithic message could not handle.
Early on, it became clear that changing the monolithic message was going to be difficult due to so many people using it in mission critical systems. The use of the name/value pairs increased. Each name that could be used was documented inside a large spreadsheet, and developers were required to consult the spreadsheet to avoid duplication of name value function. The list got so large, however, that it was found that there were frequently collisions in purposes of name values.
The majority of the monolithic message's fields now have no purpose and are kept mainly for backwards compatibility. There are name values that can be used to replace fields in the monolithic message. The majority of the interfacing is now done through the name/value pairs. In cases where the client is intending to communicate with more than one third party, each client needs to reconcile the name values available for each third party. It would be almost simpler to interface directly to the third party themselves.
I believe this illustrates that, from a consumer of the monolithic message perspective, that it is important that developers of the consuming code not know what is happening under the covers. If the designers had considered that the consumers of the monolithic message should not have to understand the abstraction in great detail, the monolithic message and it's associated name/value pairs might never have happened. Documenting the abstraction with assertions regarding input and expected output would make life so much simpler.
As for colleges not teaching C and Lisp....they are cheating the students. You get a better understanding of what is going on with the machine and OS with C. You get a bit of a different perspective on processing data and approaching problems with Lisp. I have used some of the ideas I learned using Lisp in programs written in C, C++, .Net, and Java. Learning Java after knowing even just C is not very difficult. The OO part is really not programming language specific, so perhaps using Java for that is acceptable.
An understanding of fundamentals of algorithms (e.g. time complexity) and some knowledge about the metal is essential to designing/writing smells-good code.
I would suggest, though, that just as important is education in modern abstractions and profiling. I feel that modern abstractions make me so much more productive than I would be without them that they are at least as important as good fundamentals, if not more so.
An important element that lacked in my education was the use of profilers. When used routinely and correctly, profilers can help mitigate problems with poor fundamentals.
Since you quote Joel Spolsky, I take it your aware of his "Law of Leaky Abstractions"? I'll mention it for future readers. http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Green & Blackwell's Ironies of Abstractions talks a bit about the effort of learning the abstraction. http://homepage.ntlworld.com/greenery/workStuff/Papers/index.html
The term "astronaut architecture" is a reaction to over-abstraction.
I know I certainly curse abstraction when I haven't touched Java or C# in a while and i want to write to a file, but have to instance a Stream...Writer...Adaptor....Handler....
Also, Patterns, as in Gang Of Four. Seemed great when I first read about them in the mid-90's, but can never remember factory, facade, interface, helper, worker, flyweight....

How do I explain APIs to a non-technical audience?

A little background: I have the opportunity to present the idea of a public API to the management of a large car sharing company in my country. Currently, the only options to book a car are a very slow web interface and a hard to reach call center. So I'm excited of the possiblity of writing my own search interface, integrating this functionality into other products and applications etc.
The problem: Due to the special nature of this company, I'll first have to get my proposal trough a comission, which is entirely made up of non-technical and rather conservative people. How do I explain the concept of an API to such an audience?
Don't explain technical details like an API. State the business problem and your solution to the business problem - and how it would impact their bottom line.
For years, sales people have based pitches on two things: Features and Benefit. Each feature should have an associated benefit (to somebody, and preferably everybody). In this case, you're apparently planning to break what's basically a monolithic application into (at least) two pieces: a front end and a back end. The obvious benefits are that 1) each works independently, so development of each is easier. 2) different people can develop the different pieces, 3) it's easier to increase capacity by simply buying more hardware.
Though you haven't said it explicitly, I'd guess one intent is to publicly document the API. This allows outside developers to take over (at least some) development of the front-end code (often for free, no less) while you retain control over the parts that are crucial to your business process. You can more easily [allow others to] add new front-end code to address new market segments while retaining security/certainty that the underlying business process won't be disturbed in the process.
HardCode's answer is correct in that you should really should concentrate on the business issues and benefits.
However, if you really feel you need to explain something you could use the medical receptionist analogue.
A medical practice has it's own patient database and appointment scheduling system used by it's admin and medical staff. This might be pretty complex internally.
However when you want to book an appointment as a patient you talk to the receptionist with a simple set of commands - 'I want an appointment', 'I want to see doctor X', 'I feel sick' and they interface to their systems based on your medical history, the symptoms presented and resource availability to give you an appointment - '4:30pm tomorrow' - in simple language.
So, roughly speaking using the receptionist is analogous to an exterior program using an API. It allows you to interact with a complex system to get the information you need without having to deal with the internal complexities.
They'll be able to understand the benefit of having a mobile phone app that can interact with the booking system, and an API is a necessary component of that. The second benefit of the API being public is that you won't necessarily have to write that app, someone else will be able to (whether or not they actually do is another question, of course).
You should explain which use cases will be improved by your project proposal. An what benefits they can expect, like customer satisfaction.

Have you employed any strategies or techniques to overcome user resistance when implementing a new system?

We have been trying now for a while to assist the management (of a customer) with the implementation of a a new system that is custom developed by ourselves, to their requirements. Their old system is text based (DOS) and their employees have been using it for years. The new system is Windows GUI and have many advanced features which will make their lives easier and their organisation more efficient. The problem is that the staff do not want to adapt to the new GUI environment and they are now resorting to be unfriendly and as unhelpful as possible, often placing serious obstacles in our way. The management is adamant that implementation must proceed. The system runs trouble free. We have been consistently friendly and helpful with all parties.
Any advise would be greatly appreciated! Have you encountered something like this before and did you manage to turn it round?
Note:This question is intended to help Programmers etc. with implementation difficulties by sharing experiences and factual solutions that worked. It is not intended to be subjective and indeed Programming techniques may help to solve the problem.
Use the tool
Somebody needs to really understand how the existing tool works. Not just well enough to walk through it; but well enough to do it for real. Why not take 2 weeks and go and do their job with them? That will both improve your understanding of the tool, and may foster a better working relationship with them. And while you're there, perhaps buy the drinks once or twice - it sounds corny, but anything that lowers the hostility, and lets you communicate.
User experience
Getting a good developer (or better: designer) who understanding user-experience is probably key. You can't just completely change their tooling and expect their productivity to remain the same.
Keyboard use:
Think of tools like Visual Studio, AutoCAD, etc - in most cases you don't need the mouse, and "die hard" types wouldn't notice if you took their mouse away. Try to respect this; provide shortcuts / chords (ideally the same as the existing system).
Terminology:
Keep it the same. Don't invent new terms for things.
Talk to them?
This may or may not be possible, but getting a few key users "on board" early can be pivotal; especially if you genuinely empower them to help with the user experience.
Find the faults
In the existing system. Take away their existing pain points and they may forgive you a lot.
Unfortunately it sounds like a case of needing to close the barn doors after the horses have bolted. You really need to get grass roots buy-in on the need for an improved system before beginning the project and maintain that relationship during the development.
By having champions of the system at the "coal face" level in the business would a) make sure you meet not only the management requirements but also the users goals which is all important in a successful system and b) the users get a system to which they have been a development party not just had a system thrust on them.
Getting people to moan about the short comings of an existing system is easy. Describing possible new systems before its create in way which allows the users to comment enables them to feel some control and gives you vital feedback. Be absolutely sure to identifier those killer gripes about the old system and make sure those are addressed in the new system.
Of course this all a bit late for you. The way forward is to create a review forum with the most vocal opponents and put them in a room with you and management. Get them to defend their reasons for not wanting the new system. If you can't show how your new system is better then perhaps it isn't. If you can see how the new system might be slightly improved (the movement may only need to be small) then do that, it may go a long way to get back the feeling of involvement you missed out on before.
I would sit together with the staff or a couple of the more loud mouthed opposers, go through what they find lacking with the system and suggest some of these changes to be incorporated in a future release(s). That way they will pay more attention to your the system and also feel more a part of the process instead of just being handed something like some peon. In addition it would also help avoid any misunderstandings about the system.
Get one / more of the user to be your champion by involving them in the development process. Make sure to choose the right ones. Hopefully one that you can reason with. When launching, do a launch event. Make it a big deal. Not necessarily applied to an application, but I've seen it worked in my previous work environments. If this is too late (you went ahead without any involvement from the actual users before), well... there is always things called staff turnover, lol. Out with the old and in with the new. Make the new users your buddy :).
You have to show some kind of benefit for making the change. A demo / mockup can be useful for this. Choose a manager to demo it to and wait. Let it become his idea. Then it might move forward. Being to pushy can cause a negative knee-jerk reaction which might block further consideration of the idea.
It is sad that software often gets replaced by a management decision without any user involvement and then people wonder why the system is rejected.
I've witnessed this first hand. A guy I once worked was told to develop a new version of an application "in secret". At the end of 6 months development it was shown to the users. It didn't meet their requirements and they were angry they hadn't been involved. Needless to say the software didn't make it into production and the developer left shortly after (I felt sorry for him as he had wasted 6 months effort and actually did a real good job considering the circumstances).
The chances are that the software is inferior to the previous application- perhaps data entry is actually slower (you will be biased as you wrote it- everyone likes to think their software is better).
Re-engage with the users, do some analysis and work out what is bad about the old system. If the new system can address the grips the users have with the old system you might be able to turn this around.
Edit- who was involved in engaged with your developers? Presumably the managers at the client, who probably never use the system? This is another big mistake people tend to make- managers driving requirements.
If the old system is perfect, then it never needed to be replaced in the first place!

Best practices for developers in dealing with clients

Personally, I've found that when good developers deal with clients, they often get sucked into the after-sales support process and this process has been difficult to reverse, so was just interested to hear the various strategies that developers employ in maintaining a healthy, useful relationship that keeps clients using the right person at the right time.
So do you and, if so, how do you deal with clients?
Just a tip: Write down every single thing a client says to you.
Most of the projects I work on are done on time-and-materials contracts, which means: we give the customer an initial estimate of how long the project will take but bill for actual hours worked, whether over or under the estimate (I don't know why a client would agree to this, but they do). Once the project is "complete" and in production, we set up a service extension to the time-and-materials contract, creating a block of billable hours to cover after-sales support. When a client is aware that they're being billed for all contact with us, they tend to keep that contact to a minimum.
One other point: I've found that it's best to communicate with clients via email where possible. It's a much more efficient way to transfer information (assuming everyone involved can write), and it leaves a permanent record of what the client told you to do.
I'd go the opposite of what have been said.
The client is your number one information source
Avoid intermediaries (human and technical)
Keep tracks (not to use it against the customers, even if it can happen, but because he pays to get what he wants)
Communicate - on your initiative - in a short regular basis but for small amount of times.
Any doubt can be cleared asking the good questions. The guy don't want that ? Get rid of it (even if you like it better). The guy want that ? Why not, add time and money on the contract.
You must train your communication skills
Most of what has been said here before is essentially related to the fact that programmers usually have poor communications skills. So they fall into the typical traps :
customers give them bad info
they waste time
they get stressed
At the end, nobody is happy.
But with trained communication skills you will learn to direct when, how long and about what your chats will be, and so :
Make any deal quick and nice
Give confidence to the client
Understands what the client wants (not what he says he wants)
Ensure is satisfied with the answer (even if it's nonsens for you)
Everybody will be happier : the customer will feel good and let you work in peace while you will have the information to keep working. Eventually, the resulting software will be better.
Think talking to customer is boring ? They think it too. And paperwork is boring as well, but you must do it, so do it well instead of looking for excuses.
This is a pain we feel as well. Once you help out a customer it is too easy for the customer to directly contact the developer later on and request support. And since we usually aim to please, and probably feel sort of responsible when the application we built for them has a problem, we too often give the customer a quick helping hand.
I think that the developers should be separated from the customers, but this requires that the company has a support/concultancy department which can fix the problem instead. They in turn should be free to contact the developer, unless it's a huge company with a mainstream application where there is a less risk that the problem can be traced back to a problem with the sourcecode.
But let me tell you, I understand how difficult this is. I've been working in our consultancy shop for many years, starting from support and now I'm mostly managing the other consultants and developing. There are a lot of customers (like hundreds) who feel they have a personal relationship with me, and assume that they can call me directly even after years and years.
My tip is to make sure you have a good network of concultants and supportworkers who can help the customer for you, and have them contact you instead if they can't figure it out.
I just finished my education and am working at my first job, but here is what we do:
I communicate through a third party from the same company with "higher rank". The third party is someone knowledgeable of the requirements the software should have, but not in software engineering. When I ask about specifications, or send them proposals he distills the essence of their answers send them to me.
I think this way of working with stuff limits the amount of bullying a customer can get away with when it comes to changing specs, expanding specs etc.
For me it's especially useful since I'm only 21 years old, and people might have trouble believing I can get things done.
best practices:
Remember the client is the one who signs the checks.
Users work for the client.
Refer any user requests to the client for approval.
Always deal with the client because they understand that everything you do will cost them money.
If the client wants after the sale support and is willing to pay for it then give it to him cheerfully.
Oh and what MusiGenesis said!
The best way is to never ever ever give your direct line to a customer. Have them go through Tech support (if it exists) first. We employ this method and it works well. The software developers are the last resort - for things that support simply can't do/don't know how to fix -- such as a DBA not knowing that the servers are instanced. But it will cut down on the "it's not connecting to the internets" type of phone calls.
You could also force all support requests to go through email/secretary. At that point, you can discern which ones are critical, and which ones can be solved with a simple 'tutorial' on how to fix the problem.
And as stated above - record EVERYTHING in an exchange with a customer. Doing so prevents the 'well he said she said' deal that customers can fall into.
Then again -- if you're getting a ton of customer support issues, you should be looking at the cause of it - whether it's a training issue, or whether the software is legitimately buggy.
In our company, every developer is also a salesman. If I step over the door of a Customer then I'm in a good position to make more business.
They know me and I have credabillity because I've allready delivered to them.
I have knowledge about their business
I use my knowledge to ask questionas about other parts in their business
I plant hooks to them when I talk to them, in their best interrests of course.
I make clear that we are not a "hit and run"-company, but there to really support their business.
Maybe this is not how all company does, but I think you should use the people you have that allready has a foot inside the customers company to really work with them and make more business and tie the customer tighter to you.
I personally think developers should never interact with clients. This is why you have the Q/A team. They get requirements, hand them to developers, discuss any issues, schedule development progress meetings. If developers have questions, the go to the Q/A personnel responsible for the requirements and documentation. Developers are engineers, not salesmen or negotiators. They should be given environment to develop stable, working code without getting distracted by customer phone calls. This is how many companies deal with customers regardless of company size. In the end, your chances of completing a project on time are higher than when you customer calls up and decides to change requirements or requests a feature. Which would probably mean you have to go back a couple of iterations and change something that may break everything completed past that point.
Lots and lots of communication. Communication can be as simple as checking in with your customers by stopping by at their desks (if you are co-located) or keeping in touch over the phone. The more personal the communication is (in-person beats phone call, phone call beats email, etc.), the stronger your relationship will be.
Another good conflict resolution practice I've used is keeping as much information as possible in a single, shared place. I've used a bug/feature database (JIRA), a wiki, and even a network share drive for this purpose, but the point is that neither party has exclusive lock/write access. Updates can be made together with your customers, and there is a clear, public record of the change history of your system.

Can it be morally defensible to release a program which games an MMORPG? [closed]

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 11 years ago.
I have written presumably some of the first code to modify the memory of a popular new MMORPG in such a way as to create a macro framework, allowing for advanced automated reactions, skill/level gain, large scale data retrieval, and botting.
It's my supreme pleasure to automate tasks in this way, I can't help but think of any manual approach as "broken". In fact I find myself rather unable to complete even single player games before dissecting their mechanics and gaming them, in a specifically read-only (not cheats, per se) mouse and keyboard input only fashion. Supplementing my advancement toward a game related goal with my own programming knowledge seems natural, it's really not fun otherwise, like ignoring your firearm in an FPS.
Since I love this form of reverse engineering I assume others do as well, they'd appreciate the end result at least. I tend to feel a project should somehow "ship": be sold, open sourced, or freely distributed. "Happiness only real when shared." Otherwise it's just me and my timesink.
The problem is that there are several moral stances involved with a project of this nature:
An evil is released upon the virtual world. Those with the program have an advantage, the game is unbalanced, you've got to use, simply to be on equal footing. It's no longer about the game, but the tools, an arms race. It's like every other MMORPG. Therefore, keep the code private.
The above is inevitable, so release a peremptory free distribution to give players equal access to the advantage and potentially deny someone else a more evil™ (e.g. elitist, commercial, etc.) release. Between evils the least is selected, though its necessity is disagreeable.
Sell the program, reap the benefit of your proclivity, it's work for which you deserve recompensation, fair trade (and regardless of ToS violations). Follow the likes of WoWGlider. Is it better in fewer hands?
Keep the code private. Respect at least this much of the company's Terms of Service you agreed to.
What is a morally defensible approach? What haven't I considered? In my experience ToS agreements are a largely ineffective form of dissuasion, and the gaming of MMORPGs (and subsequently results described in #1) is indeed inevitable, but there's something to be said in not pulling the trigger yourself - or is it not so bad?
I did a poor job on the original phrasing/titling of this question, I was really looking to see if there were special circumstances when it could be morally defensible, not whether or not it would normally be, in hope my code could have constructive purposes.
As a new user I didn't realize 99% of the responses would be immediate, before my update. That said, I still received some very helpful answers regarding commercialization and the original question merited the answers provided, so: well done on that front.
I do have my answer: despite the inevitability of bots, don't pull the trigger yourself! Be the change, etc. (#3 was never on the table for me personally, but elicited some brilliant answers.)
You need to tread very lightly.
MMOGlider was a popular WoW bot up until recently. I wrote an addon for it in C# called GliderTools (GliderTools.net) which made a decent bit of money.
Blizzard recently sued MMOGlider for $6 million dollars and won. There is legal precedent now against the writing of bots and commercially selling them. The monetary damages associated with doing this are staggering. It worth noting that the crime Blizzard was able to get MMOGlider on wasn't "botting" but instead, copyright infringement. They claimed that because the bot client had to access and copy certain parts of the running games memory that this constituted copyright infringement.
Considering MDY (creators of MMOGlider) made less than $2 million dollars, they have a heavy price tag on their heads. Michael Donnelly the original creator and founder of MDY was not protected under his LLC license and he is personally liable for those $6 million dollars. This kind of debt does NOT go away with bankruptcy. He has it for life. Once you add on legal fees, appeal, etc this is a dangerous game.
I personally love writing bots. To me a game isn't fun unless I've dissembled it, wrote a patcher for it or automated it in some way. This what makes the game fun for me, not the game itself. Seeing your bot run autonmously for the first time is a real high. However, if you make a commercial product and sell it to others it becomes a different matter.
So, if you decide to make a bot I strongly suggest you either release it from outside the United States or keep it private among friends.
Earning money on annoying million of other players, on something that's close to be taken for illegal won't look good on your resume either.
Use your skills for good™, not evil.
Personally I see botting software for populare games, is like writing botnet worms.
You waste other people's time and efforts (and often money).
Would you write a virus to earn money?
I've been building (but never selling) bots for online poker and chess for over a decade (insert promotional web link here) so this question caught my attention. I agree with #Simucal in that you need to tread lightly, especially where MMORPG's are concerned. Blizzard in particular has a draconian stance towards automation.
4.5 million copies of EULA-compliant spyware
Then again, the idea that a private company's TOS/EULA = LAW is a bit of herdthink. The moreso when that company markets to a worldwide audience across international borders. This introduces additional complexities into the TOS/EULA, which is already a vague piece of legalistic verbiage in the first place. The common practice is to structure the TOS/EULA to make it as aggressive, all-encompassing, and wide-reaching as possible. This is just good legal sense. It doesn't necessarily mean that every line of the TOS is legally binding. A TOS is a deterrent and the company will insert whatever language they think they can get away with, and hope it holds up when/if it's tested in court.
Nothing wrong with this.
At the same time, building a bot is, in and of itself, neither morally or ethically wrong. There's a very strong and convincing argument to be made that provided your bot doesn't actually "hack the servers", you have every right to run whatever piece of software you like on your machine in the privacy of your home. This is especially the case when the servers are inundated with bots anyway, so by not running a bot you put yourself at a disadvantage. Everquest PVP (for example) has been dominated by botting pretty much since the beginning.
Anywhere, there are two important criteria to consider:
Does the bot depend on information which other player's don't have?
Does the bot enable superhuman reactions, stamina, or coordination?
This puts wallhacks (unfair information) and aimbots (superhuman reaction) firmly in the "unfair/cheating" category. On the other hand, a simple farmbot is most probably NOT cheating, because the bot doesn't have access to any insider information and it doesn't allow you to do something you couldn't otherwise have done. You could, if you wanted to, sit there for 10 hours a day and farm ore or roots or whatever. It's not much fun, but you could easily do so.
This is a good acid test for whether your use of automation has crossed the line. Trying to cheat people is a bad idea. But writing a bot to essentially ward off carpal tunnel is understandable, and it can actually be a rewarding project.
But again, I wouldn't advise actually selling a bot. Because if you make any money on it, you open yourself up to the sort of retaliation #simucal mentioned.
Just because other people will make similar bots does not make it morally OK.
These games are, at the end of the day, supposed to be fun. As you said, bots turn the game into an arms race, especially if the game has any competitive component.
Here's an example from my experience with World of Warcraft: I wanted a specific item crafted. The materials for this were hideously expensive on my server; the large number of rich players (who may or may not have gotten their gold legitimately) had pushed the prices up to a point where I couldn't afford it.
My only option was to farm the materials myself. Many of these required killing huge numbers of monsters for days at a time. One particular item had something like a sub 1% chance to drop. And almost every single farming spot was being run continuously by bots.
It's hard to compete against something that doesn't sleep or take breaks. You can't simply wait for them to go away because they don't. Because I played by the rules, my goal was made far harder than it should have been.
It's hard to have fun in the game if there are people willing to ruin your experience out of laziness and greed.
So no, I'd say it's not morally defensible. You know full well that what you create is going to harm people.
The real question is, do you have a problem with that?
If you've described your true feelings here, then the fun was in solving the problem, not in creating a product. If others appreciate this kind of thing they'll do it themselves.
In my opinion, you cannot have a morally defensible position when in order to being solving the problem interesting to you, you agreed to terms and conditions prohibiting you releasing your work.
The problem with this is that it reduces most of the game down to just one thing: end-content.
Take World of Warcraft for instance, I love playing that, and I love leveling up a character. Sure, there are some tedious points in the process, but by and large, it's fun.
Now, if I had installed a bot and just put it to work leveling up my character, at least doing all the repetetive work and leaving me with just visiting a trainer NPC and getting my new skills once in a while, then all I had left was the things I could do at level 80.
Additionally, all the skills I, as a person (not my character) should've learned along the way goes out the window.
There are two types of people that are beyond good in Counterstrike, as an example, it's the people that use bots, and it's the people that have just played so much that they are that good.
Once you resolve to using bots, you're pretty much doomed to keep using them, and trying to automate your end-content playing as well, since you really don't have the experience to play at that level.
So basically, you're reducing the whole game down to a programming contest.
Even if you keep you code only to yourself, all you've proven is that you can program. You've yet to prove that you can play the game.
So in the end, what actually is the point of you playing that game then?
As others have said, there's many options available to you if all you want to do is create software to automate things.
Having said that, I share some of your joy of controlling my environment. I use regularly quite a lot of addons in World of Warcraft, but they don't give me an advantage over others in the same way a bot would. They might make it easier for me to organize my inventory, let me keep notes inside the game, or just prettify the user interface, but in the end, it's still me that pushes the buttons in response to game events.
And that's what gaming is about for me.
Progression requires unethical choices. My advice is Go Ahead and "reap the benefit of your proclivity, it's work for which you deserve recompensation [...]". Why are you ever worried about this? Release the hounds and let others fight it if they can. Take a history book to see thousands of similar decisions made. It pushes humankind forward.
I'm a big multiplayer gamer myself, and played so many MMORPG.
When I see someone cheating in an online game only one sentence is out of my mouth "What a wank*r!"
Morally it's wrong to mess up other people's fun, and if you try to make money out of it it's not any better than running a SPAM company.
To be honest personally I don't care about farming bots, playing a game which requires constant farming sounds stupid to me anyway. But still there lots of people out there who cares, and you these tools definitely spoiling their fun.
I understand it's a fun challenge, keep it private have your fun, tell your friends and show off, but do not kill other people's fun.
In my opinion a ToS holds no one back [...]
So, by using the MMO, you agree to the ToS; but it's OK to break the rules, because you don't agree with the ToS? Nice doublethink, but the court would probably ROFL at such argumentation.
You see, the basic idea of ToSes everywhere is "it's our way or the highway" - by using the service, you agree to play by the service's rules; if you don't like the rules, nobody is forcing you to use that service, you can freely walk away.
Also, don't try to be "clever" and release the bot in Elbonia just because its jurisdiction allows that: the ToS probably states that server's jurisdiction applies (which can bite you if you ever decide to visit the country in question, or even another country which has extradition agreements with it).
Disclaimer: IANAL
If you been following the Blizzard versus MDY case, and the recent outcome, I would strongly recommend you to keep code in private if you're located in the US, or any country with Intellectual Property laws.
Also #3 , selling it will only get you into trouble. MDY went bankrupty, is not allowed to sell their product anymore, had to hand over the source code, and pay Blizzard 6 million USD in damage.
The author, Michael Donnelly, is likely to end up in dept for the rest of his life.
I recommend you keep it private.
As opposed to Blizzard and WoW, take a look at Ultima Online and OSI as to they allowed 3rd party tools, and even supported them (Tugsoft's UOAssist).
To me it's morally fine, if the game is designed in such a way that grinding one thing only leads to grinding another thing, and if the grinding in general is done in really unpleasant manner then, hey, why not? If it's allowed, everyone has an equal chance, as everyone can use the particular supported 3rd party product, this is a chicken-egg question.
It's mostly forbidden because it reduces the time you need to spend in the game, effectively reducing the time you're paying them for their service, so, greed or fun?
As a sidenote, I'm all against unattended macroing, it's a huge difference between attended and unattended.
Yes, it is fun to reverse engineer games and to do automation. From your question it sounds like you're asking where to go from there.
A) It violates the ToS, so you shouldn't use it yourself.
B) It violates the ToS, so you shouldn't sell it.
My impression is you're looking for an OK to do one of those two things, while admitting that the fun was in writing it. I would suggest you take the entertainment value from writing things for what is, and assume your "fun" time is not worth any money. Particularly at the expense of others.
The ToS holds no one back? Check with Blizzard, they are not pleased by such things It's definitely in their ToS not to run any programs that mess with WoW). The companies running these MMO's try pretty hard to stop such programs because they lead to unfair advantages and ruins the economies.
If you like doing these kinds of things, you can also look at non-MMOs. There are plenty of games (e.g. TES:Oblivion and Fallout 3) that have very active modding communities which are tolerated and even supported by the game developers.