I noticed in the optaplanner examples, specifically the nurse rostering example, the GUI updates with the current best solution found.
I'd like to mimic something like this in my app but I'm unsure how I can get the current best solution after calling, for example solver.solve(roster);
Furthermore how would I be able to even update something on, let's say, a GUI if I'm "stuck" in the solver() method while solving.
I'm looking for some basic direction on where to start because I cannot find anything in the user guide, but I might just be blind.
Take a look at listing to new best solution events in the manual.
I would like to make a 2D iPhone game, I've done some research and Cocos2D does seem like the best option, I am just wondering how much knowledge of Objective-C I will need before tackling Cocos2D. I know the fundamentals of programming in Objective-C - I can make a basic command line tool app. I've done some iOS SDK tutorials but I wouldn't know how to make an iOS app if I was asked because the tutorials I'm currently following are about three years old.
What is required as prior learning before using Cocos2D and does anyone know of any good resources? I'm more of a visual learner so I find videos more helpful than books or blog posts.
Thank you in advance for your time and any help :)
There is no required prior learning. Use it. If you get stuck on something, look it up, google it, or ask a question.
Meaning: don't waste your time learning general concepts without actually being in the situation of having to apply them.
Analogy: you don't need a PhD in mechanical engineering to drive a car - though it might help when you run into any issues. But in such a case just do what 99% of all people do: call for help. It hardly makes any sense to first learn the potential problems you can have with a car, you deal with them as they happen.
Also: frustration is part of the game and can not be avoided. :)
how much knowledge of Objective-C I will need
A lot. You need to master Objective-C before trying to make a bigger project like this.
And to understand Objective-C, you need to have a very solid knowledge of C.
(Also, for using 3rd-party frameworks lile Cocos2D, make sure you understand well the basic, default libraries such as Foundation and UIKit.)
For making games like Free flow , having an intermediate knowledge of Objective-C is sufficient. But if you plan on make something like Temple Run, then you need really good knowledge of Objective -C,Open-Gl and cocos2d..
The site I would recommend is raywenderlich.com, that's where i started from and they have tutorials from really basic level to really advanced level.
Hope this helps
The answer to that depends truly on who you are, your work ethics, and how much effort your are ready to consent to that effort. I would argue that if you have solid foundations with other OO language/frameworks, your quest is possible. I would start by 'repurposing' a freely available game ( you will find many good examples and tutorials from Ray Wenderlich and also Steffen Itterheim. Pick a sample project that is not too 'distant' from your game specification, and repurpose it. In doing so, you will break-in to objective-C and some of the basic frameworks you need to comprehend. Mastery will follow if you are dedicated and stick to it. Also, SO rules : many answers are available here : appropriate questions will yield many helpful hints and solutions to point problems.
ps. My biggest learning curve turned out to be xCode, a truly arcane and dogma-ladden IDE. I since switched to another IDE and my productivity has gone back to respectable levels.
I recently picked up Objective-C and cocos2d at the same time. I did a lot of reading about objective-c in the beginning to give me a primer. Aside from the syntax, most of that knowledge remains unused in my game. The most important things to learn about objective-c before starting in on cocos2d tutorials are, memory management, and debugging.
The reference count memory management might take a minute to get used to depending on what languages you are coming from. The general rule is, if you alloced/copied (without autorelease) or retained it, you must at some point release it, and if you need to use something beyond the current scope, you should retain it. You can see from some cocos2d examples of overwriting an objects dealloc method in order to dealloc anything you created/retained.
The debugging took me a minute to get used to as well. It helps if you add a high level try/catch block that you can use to log uncaught exceptions, otherwise some of your errors will give you little info to go on. You may also want to research/mess with some of your project settings to allow for better bug catching, such as enabling zombies. A big causer of crashes in objective-c is sending messages to already dealloced objects. Once you come across a badaccess error that you can't figure out, you will basically be forced to get knee deep in this stuff in order to figure out the cause.
Some other purely objective-c knowledge that will come in handy are getting very familiar with how NSArray and NSDictionary objects work, how they automatically retain/release, and how they can only hold objects (no primitive values). To work with floats/int and arrays/dictionaries, you need to convert primitives into something like an NSNumber object, which can be done fairly easily with a little research. Another helpful too is knowing how to save/load plists. There are convenience methods for doing this on NSArray and NSDictionary objects. This along with a little knowledge of the NSFileManager should be enough to help you save/load game states. If you want to get really fancy/clean in your coding, you will also learn about observers in objective-c. KVO can be great for making your UI update automatically on a certain objects property changes. For instance, my HUD KVOs the player object's life, so that when the life value changes, the HUD automatically updates. This can allow you to make a cleaner MVC type application. You can also register to listen to other types of messages (not just property changes), just make sure to unregister your listeners when you are done listening.
My last bit of advice would be to always pay attention to XCode warnings. If you are getting one, and you don't know why, you should figure out why. Some simple ones you might be able to ignore, others may cause bugs that you will not be able to track down any other way. For instance, I once used the function max() in my code, and xcode gave me a strange warning that I didn't understand. This caused havoc on my program by corrupting the stack. When I changed max() to MAX(), three or four unexplained bugs instantly disappeared. This kind of thing can set you back weeks, and take serious combing through every piece of your code if you don't catch it right away.
The rest can mostly be learned by looking at cocos2d code/examples. Good luck.
I am new to iPhone-Programming and I am probably asking a beginner's question, but I really couldn't find a satisfying answer to this:
I would like to understand the underlying architecture or structure of an iPhone App. What comes first, what are the parts that a starting template usually does automatically? In C-Programms, you know the program always jumps into main and then everything starts like you coded it. In iPhone-Programming, we start also in main and then something like the event loop starts and etc.there is a lot going on under hood, which I would like to understand so I feel more confident writing code and actually being aware of all consequences that my code causes.
I would be happy about any answers or are there any good references that are compact and only focussed on the coding architecture?
Read this for example ... http://www.technolike.com/archives/86/core-application-architecture-for-iphone.html ... and Google for more. There are many resources how to iPhone application starts, what's going under the hood, how event handling cycle does work, etc. Also when you read these resources, try to ask more specific questions. It's too broad question to answer everything.
I suggest that you browse through Apple's documentation on iOS development: http://developer.apple.com/library/ios/navigation/
If you want to learn the low level stuff first, perhaps you should look into how Objective C works and then move to learn about UIKit (which is the central framework/library for iOS app development).
More often than I'd have hoped I seem to come across method/property definitions in Apple's documentation that are vague at best and meaningless, to me, at worst. For example, take the following method description from NSNumberFormatter Class Reference:
setPartialStringValidationEnabled:
Sets whether partial string validation
is enabled for the receiver.
- (void)setPartialStringValidationEnabled:(BOOL)b
Parameters
b YES if partial string validation is enabled, otherwise NO.
So, let's just assume that the shoddy educational system I went through and any previous projects I've worked on didn't cover "partial string validation" in Cocoa and I would like to dig into it some more to see what this property is all about. Where does one look (aside from Google)? I hate to pester forums for something I should be able to look up easily myself.
I have come across situations like this enough times now that I think I may be approaching Apple's docs incorrectly. Any suggestions? Tips/tricks? 3rd party resources?
Partial string validation is explained in NSFormatter class.
Setter methods like that are sometimes explained in more detail in the getter method, the introduction text in class documentation, or one of the documentation companion guides you see linked on the bottom left. Sometimes you can also find clues in the Cocoa headers, by right-clicking on the name when you're writing code and selecting 'jump to definition'.
Otherwise, there's really no other resource other than google, asking about it on sites like this or using a mailing list. You could always write some code to test what happens when you change its value. And of course, if it's something really confusing it's good too to take the time to file a radar bug report so it will hopefully be improved in the future.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I work on a complex application where different teams work on their own modules with a degree of overlap. A while back we got a Mediawiki instance set up, partly at my prompting. I have a hard job getting people to actually use it, let alone contribute.
I can see a lot of benefit in sharing information. It may at least reduce the times we reinvent the wheel.
The wiki is not very structured, but I'm not sure that is a problem as long as you can search for what you need.
Any hints?
Some tips:
Any time someone sends information by email that really should be in a wiki, make a page for that topic and add what they put in the email. Then reply "Thanks for that info, I've put it into the wiki here so that it's easier to find in the future."
Likewise, if you have information you need to share that should be in the wiki, put it there and just send an email with a link to it, rather than email people.
When you ask people for information, phrase it so that putting such documentation in the wiki should be considered the default or standard: "I searched in the wiki but I couldn't find it. Have you put that info up there yet?"
If you are the "wiki champion", make sure other people know how to use it, e.g. "Did I go through how to create a new page with you yet?"
Edit the sidebar to make sure it is relevant to your work.
Use "nav box" style templates on related pages for easier navigation.
Put something like {{Special:NewPages/5}} on the front page, or recent changes, so that people can see the activity.
Take a peek at Recent changes every few days or week, and if you notice someone adding information without being prodded, send them an email or drop by and give them a little compliment.
As I mentioned before, a Wiki is very unorganized.
However, if that is the only argument from your developers, then invest some effort to create a simple index page and keep it updated (either do it yourself or ask people to link their contributions to the index). That way, the Wiki might grow into a very nice and quite comprehensive collection of documentation for all your work.
We've been using a wiki in some form or another for a while now, but it does take a while for people to get on board. You might find that you will be the only one writing articles for some time, but bear with it, other people will come on board eventually.
If someone sends an email around that contains information related to the project then helpfully point them in the direction of the wiki - and keep doing that - they should get the hint.
We have a SharePoint portal and use the wiki from there - we customised it with our own branding so that it "looks the part" - I really feel this has helped to improve the uptake of it.
Make sure that everyone is aware that the wiki is even more informal than email.... because there will be a "fear factor" that people may think anything they add to the wiki will be over-analysed.
I think most of the answers so far are spot on - the more you plug away at it yourself, the larger the body of useful information will become, so slowly but surely people will naturally start to use it.
The other approach you could use is this: Suggest that every time someone asks another team member a question about the project, they should answer the question as normal, but also add the answer to a section of the Wiki. This may take a few minutes extra, but it will mean that the next time someone asks the same question (which they inevitably will), you can save time by pointing them at the Wiki. This, in turn, should help people to start using the Wiki as a first source of information and help overall up-take.
You can't force developers to do something they do not have an incentive of using for; unfortunately wikis, like documentation (well, in fact wikis are documentation) rarely have any "cool" value for developers. Besides, they're already deep into dev work -- could you really bother them with a wiki?
That being said, the people who pushed for the wiki (e.g., you) should be primarily responsible for updating it, and you really would have a lot of work cut out for you if you're serious about it.
You might also try the ff:
It's not very structured you say -- a lot of people get turned off from ill-structured (hard-to-search/browse) wikis. So maybe you can fix that first
Maybe you can ask lead developers/project managers to populate it with things that are issues for them: things like code conventions and API design for your particular project
Lead by example: religiously document your part of the system. Setting a precedent may encourage others to do the same
Sell the idea of using the wiki to the developers. You've identified some benefits, share those with the developers. If they can see that they'll get something of value out of it they'll start using it.
Example advantages from What Is a Wiki
Good for writing down quick ideas or longer ones, giving you more time for formal writing and editing.
Instantly collaborative without emailing documents, keeping the group in sync.
Accessible from anywhere with a web connection (if you don't mind writing in web-browser text forms).
Your archive, because every page revision is kept.
Exciting, immediate, and empowering--everyone has a say.
I have done some selling and even run some training sessions. I think some people are turned off by the lack of WYSIWYG editing and ability to paste formatted text from Word or Outlook. I know there are some tools to work around these, but they are still barriers.
There are some areas where the wiki is being used to log certain areas, but people who update those are not doing anything else with it.
I will use the wiki to document my specialised area regardless as it acts as a convenient brain extension. When starting a new development I use it as a notepad for ideas that I can expand on as it progresses.
It would help if management would give it some vocal support, even if it is not made mandatory.
I have a hard job getting people to actually use it, let alone contribute.
One of the easiest ways to get people to contribute to a wiki, is to actually have them provide contents in a wiki-suitable fashion, i.e. so that whatever they post using their usual channels of communications (newsgroups, mailing lists, forums, issue trackers, chat), is basically suitable for inclusion on the wiki.
So that others (users/volunteers) can simply take such contents and put them on the wiki.
This sounds more complicated than it really is, it's mostly about generalizing questions and answers, so that they are not necessarily part of a conversation, but can be comprehensible, meaningful and useful in a standalone fashion.
For example a question like the following:
how do I get git to clone a remote repository???
Can be answered like this:
Hello,
Just use git clone git://...
But questions can also be answered in a less personal style:
In order to clone a git repository, you will want to use the clone parameter to git:
git clone git://....
What I am trying to say is that most discussions in a project can and should be easily used to become documentation eventually. With this sort of mindset, your documentation can actually grow rather rapidly. You only need to get people to keep in mind that useful information should be ideally provided in a fashion that is suitable for wiki inclusion.
I have witnessed several instances where open source projects started to use this approach to some extent and while some people (largely new users) complained that answers were not very personal, the body of documentation was increasing steadily, because other people simply monitored such discussions and started to copy/paste such responses to the wiki.
Basically, this is one of the easiest ways to get people to contribute to a wiki, without requiring them to actually use it themselves, the only thing that's required of them is a shift in thinking.
If the developers still need to maintain 'real' documentation (s.a. Word documents), I see no way to meaningfully duplicate that on a Wiki.
It does not make sense for people to write twice
Any duplicated data is prone to get out of sync, soon.
What my current customer has done is move all this to Wiki. So I only document once, and I do it on the Wiki.
This is okay. Working with Wiki is more tedious than with Word, but at least the doc is online and others can mix-and-match with it.
Another working solution (imho) would be to store docs alongside the source, on subversion. But then the merging system needs to be able to cope with rich text etc. as well. I don't know, if any solution for that exists (other than using HTML or LaTex, which actually would not be bad picks).
Find "sticky" items (sub-3 pg. docs / diagrams / etc) something that the team seems to be creating again and again & post it on the wiki. Make sure everyone has access to the wiki and knows its there - set up a notification mechanism if possible. With some luck, the next time they have to access, rather than dig it out of version control or their machines - they should hit the wiki.
If they still don't, try to see if the team has enough slack to actually use the wiki - Subtler issues may lie beneath their reluctance.
Take a look at the advice at http://www.ikiw.org/ Grow your Wiki
Just to add to some of the excellent advice being offered here...
As a dev in a small company that does largely gov't contract work in the 6-24 month range, I find that my time is often split between development and writing status reports (right up there with writing documentation, only worse!) Having a wiki to slap down unorganized thoughts and notes as we go along has made report-writing a lot less painful (not pain-LESS, but better all the same).
Further, if you're already in the Mediawiki world, you might want to look at SemanticMediawiki. It allows you to take the organization of your data to another level by semantically tagging it. That doesn't mean a lot on its own, I know, but I can tell you (for example) that it can drastically improve the relevance of the data returned from searches. It is definitely worth a look.
Generally good advice here. I'd like to add:
You really need a champion - someone pushing this to developers and management (without being pushy - that's a challenge!) and providing support & tutorials when possible. This person also needs to be a peer (so a fellow developer, not someone in a remote IT department) and really customer focused i.e. ready to make changes when requested.
Speaking of changes, some people here say wikis are unstructured. I disagree. Our MediaWiki installation is structured using categories, particularly with two extensions:WarnNoCategories (to require users to add a category when saving a page) and CategoryTree to show how all the categories fit together (this can be linked to from the sidebar). I've got more tips on how we keep this low threshold, if you're interested.