I've been looking for first-hand information on the World of Warcraft addon API. There are a couple wikis that are pretty good, but their reference links only point internally. Surely there is some information published by Blizzard on the topic.
Can all of their information really be gleaned from reverse-engineering and forums? That would be hard for me to believe.
Its not all necessarily gleaned from inspection or trial and error. Some is provided, but randomly, from "heads up" posts in the forums from "the source", as in Blizzard employees. They are usually pretty good about it, though is almost always provided in a "just the essentials to save you some pain" sort of way.
Here's an example:
http://blue.mmo-champion.com/topic/233590-mop-changes/
Watching for the "Blue" posts goes a long way, and its been this way for a long time. If you look at someting like this (old 3.1.0 end user patch notes) http://us.battle.net/wow/en/game/patch-notes/3-1-0 , and then scan to near the bottom there will be a note and link for API changes, so its easy to glean their intent on this, and that they intend to provide some "unofficial" support about API changes there whilenot burdening the actual product readme with them.
In general, I'd say that due to the very open nature of the materials, the source for the UI, very little is hidden and most is pretty self-evident, so it sort of barely qualifies as reverse engineering. Once you understand the Lua relationship to the general design of the WoW UI and supporting API, it's much easier.
As for the implied question about "why", the "hard to believe" part. They are doing, in my estimation, what they believe is the best balance between fully supporting without "officially" suporting, and not wasting cycles trying to document a huge amount of available facilites thats ever changing. I think they belive it makes a better product, having the ability to customize, so its intheir interest, however is frought with problems and even legal issues from many angles to be expressly "official" about it or to try to maintain coherent docs.
----
Toward the question "git hub" below, here is the "blue" post in context, which can be found by clicking the "blizz" link icon on the mmo-champion link provided before: http://us.battle.net/wow/en/forum/topic/6413172918#1 I was trying to give an example of a Blue post that had detail, but I accidentally gave one for the Web API not the Game API. However the principle is the same, and provides more Blizzard to Community context for dev support.
So basically that particular post was in reference to changes in the Web API, and the Git remark has no relevance to the game UI Customization and Macro thing. There is no hidden or official doc source for game UI Customization and Macro. Mostly its because it simply doesnt exist for anyone. :)
Yes, all the information is gleaned from the source.
Blizzard doesn't post the API information at this time, AFAIK.
http://www.wowpedia.org/Portal:Interface_customization is likely to be your best resource.
There are multiple ways to discover the names of callable C functions exported into the Lua environment.
But yes. One quite simple one would be to enumerate all the globals in the source that are written to, then enumerate the globals that are exposed while WoW is running - and take the difference, perhaps limiting the result to globals of type 'function'
Blizzard used to informally document its API for a while, but it has always been 'unsupported'
There are other ways to discover the API - but they involve doing things which may violate the TOS.
There is a website now that contains the API for wow addons. This has been helping me a lot.
Related
For example, are they using Java/Struts? Or ASP.NET? Or PHP? Or some combination of technologies?
Not sure how public they are about their infrastructure, but it would be very interesting to know what they use.
Not sure if this is what you are looking for, but see here: http://en.wikipedia.org/wiki/Second_Life#Technology
As is often the case with such questions, High Scalability has an overview of the Second Life architecture, plus links to presentations by SL staff and other resources.
I will take a wild guess, a combination of scripts running on a server written in C++.
While this is an antique question, I'm surprised that no one mentioned OpenSimulator or some other Sim application. OpenSimulator will allow you to run your own Second Life clone on your own hardware and with one of the many SL viewers that are out there, you could just connect to your own virtual world. And this World would be very similar to SecondLife, including it's scripting language!
OpenSimulator is written in C# back in 2007 using the Second Life Protocol to be very identical, although they don't strive for complete compatibility.
The Firestorm Viewer is also open source as Linden Labs once published the source code of their viewer using an LGPL license. But the Firestorm team doesn't make access to the source code easy to find. (It is here!) You will need to know C++ to understand the code.
So, Second Life is made from three parts: Server, client and a special protocol that goes in-between. As Second Life is old, it also uses some older techniques and protocols as developers generally don't fix things that aren't broken. Then again, this question is also old and I'm not even sure if anyone is still interested in Second Life.
Still, if someone is still interested then this gives some nice additional information.
Let's say that you have to implement some functionality that is not trivial (it will take at least 1 work week). You have a SDK/API/library that contains (numerous) code samples demonstrating the usage of the part of the SDK for implementing that functionality.
How do you approach learning all the samples, extract the necessary information, techniques, etc. in order to use them to implement the 'real thing'. The key questions are:
Do you use some tool for diagramming of the control flow, the interactions between the functions from the SDK, and the sample itself? Which kind of diagrams do you find useful? (I was thinking that the UML sequence diagram can be quite useful together with the debugger in this case).
How do you keep the relevant and often interrelated information about SDK/API function calls, the general structure and calls order in the sample programs that have to be used as a reference - mind maps, some plain text notes, added comments in the samples code, some refactoring of the sample code to suit your personal coding style in order to make the learning easier?
Personally I use the prototyping approach. Keep development to manageable iterations. In the beginning, those iterations are really small. As part of this, don't be afraid to throw code away and start again (everytime I say that somewhere a project manager has a heart attack).
If your particular task can't easily or reasonably be divided into really small starting tasks then start with some substitute until you get going.
You want to keep it as simple as you can (the proverbial "Hello world") just to familiarize yourself with building, deploying, debugging, what error messages look like, the simple things that can and do go wrong in the beginning, etc.
I don't go as far as using a diagramming tool sorry (I barely see the point in that for my job).
As soon as you start trying things you'll get the hang of it, even if in the beginning you have no idea of what's going on and why what you're doing works (or doesn't).
I usually compile and modify the examples, making them fit something that I need to do myself. I tend to do this while using and annotating the corresponding documents. Being a bit old school, the tool I usually use for diagramming is a pencil, or for the really complex stuff two or more colored pens.
I am by no means a seasoned programmer. In fact, I am learning C++ and I've been studying the language primarily from books. When I try to stray from the books (which happens a lot because I want to start contributing to programs like LibreOffice), for example, I find myself being lost. Furthermore, when I'm using functionality of the library, my implementations are wrong because I don't really understand how the library was created and/or why things need to be done that way. When I look at sample source code, I see how something is done, but I don't understand why it's done that way which leads to poor design of my programs. And as a result, I'm constantly guessing at how to do something and dealing with errors as I encounter them. Very unproductive and frustrating.
Going back to my book comment, two books which I have ready from cover to cover more than once are Ivor Horton's Beginning Visual C++ 2010 and Starting Out with C++: Early Objects (7th Edition). What I really loved about Ivor Horton's book is that it contained thorough explanation of why something needs to be done a certain way. For example, before any Windows programming began, lots of explanation about how Windows works was given first. Understanding how and why things work a certain way really helps in how I develop software.
So to contribute my two pennies towards answering your question. I think the best approach is to pick up well written books and sit down and begin learning about that library, API, SDK, whatever in a structured approach that offers real-world examples along with explanations as to how and why things are implemented as they are.
I don't know if I totally missed your question, but I don't think I did.
Cheers!
This was my first post on this site. Don't rip me too hard. (:
What behavior have you had to implement in your Rails applications that you feel could exist nicely as a plugin?
What plugin functionality have you searched for in the past but couldn't find?
What existing Rails plugins could be improved or extended, and how?
I'd like to see an engines plugin that dropped in an admin interface that provided a dashboard summary of all the models in the app, with configurable activity charts.
I once wrote a component for an application that did uploaded a zip of photos to an application so they didn't have to be done one by one, I think I may make that into a plugin when I have time, well a new version of it, the code's a little ugly.
Not easy to answer. Everyone is biased towards his own current projects. Additionally a lot of great plugins already exists.
Personally I would like to see some menu plugin for a typical data base application. E.g. where there are few user roles, and every user role has different rights. And a main menu with sub menu which depends on user's rights to actions.
A (CSS) menu is reimplemented in almost every data base application. It is rather given application specific thing and I don't know how hard it would be to implement some general solution or template.
A Credit Card Payment System
Right now, no one bothers implementing credit card payments until a site has become "production quality". Single-person projects or small startups don't bother making this at first b/c they would much rather spend their time prototyping new, hard, or interesting features.
This is bad in the long-run for everyone, including end-users, b/c the default is to offer (often innovative and really great) services for free, which means only already-funded teams or people with lots of extra time can even get to the point of making something.
If this existed, were packaged up neatly, and were as dead-simple as Rails scaffolding, small projects could default to whatever payment scheme that actually made sense -- like pay-per-use, donations, trial periods, first 5 free, etc. -- making it possible to fund the really great products out there, instead of forcing them to rely on outside funding or ads, which ruins the product.
In a real physical store, people expect to pay. If the person on the other side of the counter gives me something for free (w/o buying anything at all), I say "Are you serious??" and walk away bewildered. But online, I almost expect it. This is bad! Because now everyone expects it, and people trying to make great things can't focus on actually doing that b/c they are too busy trying to figure out how to make it great and free.
Oftentimes, there are free things out there online that I like so much that I would like to pay for, but there's simply no easy way to do it. And I'm not alone. I use tipjoy and have donated to things that have a PayPal donation setup like Auditorium, but I don't see these as adequate.
The best thing out there that I've seen is RailsKits. But as far as I understand, they aren't packaged properly so that I can add them to my site whenever I please like a plugin or gem.
I'd like to see some sort of in-built video playback/streaming. I need it for my current project.
I agree with Greg... there are lots of great plugins, and lots of great ideas for more.
I think there's always a need for more web APIs to be supported. As we go forward with API driven services and semantic web, there's tons of work to be done on that front.
http://www.programmableweb.com/ is a great starting point for thinking about what really useful APIs don't have a rails plugin or ruby gem yet.
Cheers!
Walt
What is the current state of the art in rails for preventing spam accounts? Captcha? Any good plugins, tutorials or suggestions?
Use a library: You're (almost) always better off appropriating code from people who are better at the subdomain than you are. The Wordpress guys behind Akismet have forgotten more about blog spam than I know, and I was an email anti-spam researcher for a while. You might be interested in a Rails integration plugin for Akismet.
Defense in Diversity: Spam is a quirky problem, in that the more popular a countermeasure gets the worse it becomes. As such, particularly for low-profile sites, you can get disgustingly good results by coding simple one-off tripwires. I won't give you any code to copy/paste because it defeats the purpose of the excercize: having a countermeasure which is globally unique.
One simple example is having a hidden form element which starts as some randomized string, and which is set to a known good value by Javascript code. You then bounce anything which doesn't have the good value supplied. This blocks clients which don't implement Javascript, which includes the overwhelming majority of spam scripts. There are issues, of course, as some legitimate clients also block Javascript -- but realistically, if you're using Rails, I'm guessing you're sort of assuming cookies are on and Javascript works.
I also recommend ReCAPTCHA, both because it's a highly-reliable service you don't have to manage, and because it serves two common goods - the OCR tasks described by the ReCAPTCHA team, and the progress towards teaching people how captchas work, reducing abandonment rates.
Edit:
It appears BranBuster is dead (this was years ago). But I really like:
https://github.com/matthutchinson/acts_as_textcaptcha
I'm a big fan of the rails plugin called "BrainBuster". It's a logic-based CAPTCHA which I find preferable over the "type these words" things, because it is annoying to decipher the words sometimes... It's simple to look at "What is 10 minus 3?" and come up with the answer. YMMV:
https://github.com/rsanheim/brain_buster
There is a re-captcha plugin if you want to use captch to verifye that only human can register, or add content: http://ambethia.com/recaptcha/files/README_rdoc.html
Spam is fair. It doesn't care what you're running behind the scenes.
So by extension, the things that work well on Rails are the same things that work for PHP, ASPNET, etc. Take a look at Akismet and the various "karma" anti-bot tools there are about.
For some there are existing ruby ports but you might have to rewrite a few to task.
For account creation, you may want to use Captchas. I personally am not terribly fond of them and I don't think they are that effective. But if you use them, I strongly suggest you use a service instead of trying to whip up your own. Re-captcha comes to mind. Not sure if there are wrappers for Ruby or Rails, though.
To prevent spam content, however, I strongly suggest Defensio (disclaimer: I've worked there in the past). It uses state of the art spam filtering techniques like what's used for email, such as bayesian filtering. There are plugins for many blogging platforms, including Mephisto (made with Rails). The API is simple and you can look in a few places to get working examples of how to use it with Ruby.
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
In pair programming, the experience of every member of the team can be spread to new member. This experience is always in sync with the code, because the "senior" of the pair knows how the code works and what the design is.
So what is the utility of design documentation in this case ?
UPDATE
I don't imply no design, I imply no documentation.
With a team which practice pair programming I think that everybody is disposable, because everybody knows the code. If the senior developer leaves, I think that there is always at least one person who knows the code, because the experience was shared before.
What if your team is larger than 2 persons?
Just because two people know a part of a system does not mean it shouldn't be documented.
And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.
For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.
Have you ever played "telephone?" I don't think you should play it with your codebase.
What if the senior programmer leaves the company/project?
The set of deliverables should be decided independently of whether you use pair programming or not.
Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.
But don't rely on the two people explaining the design to you one year later.
Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.
I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?
Pair programming does spread knowledge, but it never hurts to document that knowledge.
Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.
Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.
Pair programming, when taking as part of "Extreme Programming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.
The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.
In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...
... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.
Depends what you mean by "design documentation".
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.
The code base may be so large you can't humanly remember every detail of what you were intending to implement. A reference is useful in this case.
Also, you need a design if you are interacting with other components etc.
Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)
XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.
Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.
Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.
You could try some experiments:-
Document a couple of small parts of
the design and note how often you
have to refer to it.
Document stuff that is always a pain
to work with.
No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!
An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.
Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.
Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.
So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).
I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.
Pair Programming only enables your coding and logical aspect.
But documentation is good practice. Always do documentation...