I've been doing web programming for some time now, and don't consider myself so much of a total newbie but I still don't understand what "/path/to" is. People use that code a lot, and I used to think it's just a way to refer to main path. But I started wondering why so many people use that syntax so uniformly, because it's confusing if it's meant to be NOT taken literally. Most people would actually type in "/path/to".
So I tried searching for "/path/to" on google, but this is something that's hard to search on a generic search engine, so no luck. So I decided to ask here. Is "/path/to" some kind of jargon that people use to refer to something? If yes, what does it exactly refer to? If no, then how does it work internally?
This is just a placeholder for an actual path in your environment. I usually use it when I want to abstract from the path in question. It does not matter and the reader/user of my code will likely have it different. So I prefer to clearly indicate what places he should amend.
Other examples of this sort:
GET http://example.com
ssh username#host
/path/to/project and similar constructs are used in documentation and blog posts to abstract away details that vary on different machines and for different people. For example, I might be working on a project on my Linux machine that is at /home/code-apprentice/src/my-cool-ruby-project. At the same time, you are working on a project on your Windows machine that you put at C:\Users\Vlad\Projects\MyEvenBetterRubyProject. We both are reading the same blog article to implement a feature. The detail of the exact path where we each store our project doesn't matter for the particular part of Ruby on Rails that we are using. The notation /path/to/project is just a convenient and concise placeholder to describe the root of the project that varies between our machines.
Related
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.
I'm looking for a good wiki platform to work with RoR, I know mediawiki is great but its in PHP and I'd rather keep my code base in the same language if possible.
DHH (I think) wrote a simple wiki in Ruby several years ago called Instiki. I haven't used it in a while, but I'm sure the code is out there somewhere.
If you want an active project, there's something called Decko, which is a wiki in Ruby, but an unusual (and apparently successful) take on how to do a wiki. I've not used it, but all my poking at it suggests it's a very well-thought-out and useful approach. Find it at https://decko.org/
Here are list of wiki software written in Ruby and in other languages as well.
http://en.wikipedia.org/wiki/List_of_wiki_software#Ruby-based
Try the font of gem-ishness, ruby-toolbox.com
https://www.ruby-toolbox.com/categories/wiki_apps
I note the top 3 are all git-baseed, rather than database based, at time of writing.
I've used none, myself yet. So I guess we use number of download be a guide?
I want to make a community based site, which is Drupal's strength. However I also want to try other frameworks, especially Rails.
One of the best things about drupal is its huge modules library. If I were to switch to Rails, would I be able to find similar functionality freely available as plugins, or would I have to rebuild?
Does Rails have the equivalent of (as plugins or gems):
CCK/Fields?
Node Reference?
Views / Views Relationships?
PathAuto?
Threaded Commenting?
Multisite Functionality?
Apache Solr (or equivalent) Integration?
Thanks.
I'm afraid you'll probably hear this answer a lot, but it's not a suitable comparison.
Drupal is a ultimately a CMS, Rails is a framework. Apples to oranges, or perhaps even Apple Juice to oranges. Out of the box, you fire up Drupal and it does 'things': it has a database structure, the concept of nodes, interfaces blah, blah. If you fire up Rails you have an empty project.
As far as I know there isn't a "Drupal-on-Rails" project that would be a suitable equivalent. However, I can attest to the fact that there is an awful lot of Ruby/Rails community and O/S work out there and you might find something suitable. I'd also say that the level of modularity in Ruby and Rails tends to mean that the range of plugins/modules/gems one can use is much greater.
My personal $0.02. If Drupal does what you need, just use Drupal: it's mature and has a great community. It's never a good idea to try to port Project X over to a new language as a learning exercise because you'll inevitable fall into the "Well that's how it's done in language X!" trap and become disenchanted with the new system.
If you're wanting to learn Rails (which you should, it's awesome) I'd suggest you'd be best working on a small project and seeing what the ecosystem offers before deciding if it's suitable for the needs of your bigger projects.
I have to second what Govan said, but add to it.
With Drupal, unless you really want to get into building your own modules and extensions you are really interacting with an application. Even when you start using CCK, all you are really doing is flipping switches, filling in forms and defining new options for content on the site.
Ruby on Rails is two things, and neither of them bares much similarity to Drupal. You asked "How hard is it really?". To answer that you need to understand what both Ruby and Rails are. Ruby is a programming language designed to make the life of the object purist programmer simpler and more pleasant. So, the first part of how hard is it is simply to answer "how long do you feel it would take you to learn a completely new programming language, like PHP but different".
Rails is an 'opinionated' framework. It's opinionated in that it lays out how a Ruby web project should be structured, as well as providing multiple APIs for everything from database access to web presentation. To answer the "how hard is it" question for Rails then (assuming you know Ruby by this point), you have to answer how much do you need to learn about cacheing, database design, page design, RESTful programming etc etc.
It's not a short journey. you asked if there is an equivalent to CCK for Ruby and Rails which implies to me that at this point your knowledge of programming is somewhat limited. Ruby and Rails interact with the database. CCK lets you define things in a database. Thus, with Ruby and Rails you are effectively bypassing the wonderful dialogs and forms that CCK provides you with and doing the data definition bits yourself, by hand, in code.
From experience, when I've hired experts in another programming language and framework into my Rails teams, it has taken them between 1 and 3 months to get productive, and a further 3 to 6 months for their productivity to start to raise and approach that of the Rails experts on my team.
Thus, in your particular case, I would not recommend a switch away from Drupal to Ruby on Rails.
Drupal (core) on ohloh (130k lines of code) is estimated to be 34 years of work worth.
Drupal (contributions) on ohloh (modules for Drupal 4-6 (7M lines of code)) is estimated to be 2113 years of work.
That is the power of a community, and that is something that you can never replicate. I remeber there was a guy, who tried to port Drupal to python calling it drupy, but that project died before something useful ever came out of it. Even if you copy the code, you can never copy the community.
The thing you need to realize, is that each community is different. So even if you find a project that can solve your code needs in a RoR or a different language/framework, it will never be like Drupal and vice versa.
So don't try to find a replacement for Drupal, but go explore and try new things. You might end up learning new things, that you can use for your Drupal projects.
I've read this times and times again that people saying comparing drupal an ror is comparing apple to orange which is wrong.
I think the saying itself BS. Yes we want to compare apple to orange and find out which is better. We even want to compare apple to steak. Said that, they are different. Yes, we all know. I have limited experience with either. I first thought Drupal was great and can help me build the website I wanted overnight (or over a week or month) then it didn't happen (not blaming Drupal).
My impression is that, Drupal maybe still great but it has a learning curve and needs a lot of other knowledge or talents to use it well and tweak it. RoR on the other hand is a more general framework and needs programming (Drupal needs too actually).
If you are more of a web designer person with a little PHP maybe Drupal is better fit.
If you are more of a web developer type don't want to spend time looking for modules and make them work but rather do them yourself (not really from ground up) then maybe RoR is for you (with the same amount of learning). So yes they are both good for different purpose, background, etc.
For now I will go with RoR (or dJango and other ORANGEs). My 2 cents.
Rails, since version 3.0, has officially adopted the once-controversial engine way of incorporating third-party apps. this is roughly the equivalent of Drupal's modules/plug-ins, from a 10k foot perspective. To build a community-based site, you could make use of an engine called, appropriately enough, "Community Engine." http://communityengine.org/features.html"
The Rails ecosystem doesn't have anywhere near the same number of modules Drupalists have available to them, but there are enough good quality ones to cover the chief basics.
Drupal has so many strong areas, its hard for just one or two people to recreate it in a decent amount of time with any language. PHP, Ruby, Python, etc.
You have the core node system, taxonomy, aliasing, menus, users, permissions, and modules, the database api, and form api, among others.
You'd have to know how to assemble all these pieces independently and create the structure necessary for it to all work together.
It would take more than 'a few hours'. I would say, even if you are a ROR master, you're looking at a year to two years of solid consistent work to get the best parts of Drupal for a new system.
What is your favorite Rails admin tool and why? By admin tool, I'm referring to those that let some users add records for all the tables, like the tool shipped with Django.
This question is subjective and I believe the matter is subjective, but I think it would still be nice to be able to read other people opinions and gather data on the strength of each tool. Feel free to also comment on why you are not using a particular tool.
Looking around I've seen these ones:
Streamlined
Typus
admin_data
active_scaffold
full list
I think it would be excellent if there was one answer for and one answer against each tool and we just add information to each of them, in a very encyclopedic way, but I'm not sure if that's doable. Of course, this question is a community wiki.
In my experience Streamlined, Active Scaffold etc. often ends up limiting you and slowing you down in the long run, although it can be very efficient in the short run.
By combining the Inherited Resources and Formtastic plugins you can produce controllers and forms for your models just as fast as with a full-stack admin tool plugin, and it will leave you with greater flexibility and extensibility.
The tradeoff, however, is that neither of these plugins will give you the fancy lists that the admin tools give you. So as you say, it is indeed a matter of taste.
I've been using admin data in my last few projects and find it far superior to ActiveScaffold. When I used AS, it was always trying to do too much and that led to some problems. Admin data is completely non-intrusive. When it can't handle something in your data, it just displays a message instead of breaking your app.
I've been using ActiveScaffold for awhile. I feel that I have pushed its limits fairly far and it reacts pretty well (i.e. it's pretty robust). I customize it considerably so that non-technical users can jump in and manage their own websites with it. Those who take the initiative to work with it seem to like it. I do find the default interface confusing at times but you could change that completely if you wanted. AS is very customizable. On the downside, I've definitely grappled with my fair share of AS bugs, but the project does improve and I'm satisfied with its results. I have never even heard of the other admin systems you posted, but Typus and admin_data look nice. My biggest concern would be how easy I can customize them for use by non-techs.
I myself have used active_scaffold quite a bit and like it for certain tasks but I believe its niche is for power users not for mortals per se.
Streamlined was an interesting option but is officially unmaintained now which sucks. It really was a beautiful product but it never really seemed to get a lot of attention from the community so maybe they gave up on maintaining it publicly.
I've also not used Typus and admin_data but I ran into some references to Typus last night so clearly some very smart people are looking at it very hard.
On a last note, I think this blog post really summarizes an opinion I've come to recently after working with a Drupal firm for a bit. I believe that the reason admin interfaces haven't received the same amount of love is that Rails is built primarily for applications rather than content, which means that the people looking at backends are typically not mortals or can stand to look at an ugly backend.
I'm a Java developer trying to learn Grails, and I'd like to get exposure to as many parts of the Grails framework as possible. Preferably doing so by solving small real-world problems using the "Grails way to do it" (DRY, convention-over-configuration, and so on).
Three example could be:
Learn about GORM by creating a few classes (say Movie, Actor, etc.) and relations/mappings between them (1:1, 1:N, N:N, etc.).
Learn about the layout support (sitemesh) by using it to generate headers and footers common to all GSP:s on the site.
Learn about the filter support by using it to make sure all accesses to a certain controller comes from authenticated users.
My question goes to all Grails developers out there - what would you include in a "Grails curriculum" and in what order?
All input appreciated!
Here's some examples, but be warned that they're fairly trivial and don't really show you how the system works together. One of the strengths of Grails is that the different parts all combine to reduce your code complexity and speed development. I recommend doing a single project of moderate size (like blogging software or a photo gallery) that forces you to touch virtually everything. I'm currently working on a ticket management application, and I've had to learn basically everything in the framework. It's really not that much material, actually.
That being said, here's my list of "must study", along with some examples:
Groovy, especially closures, maps, and properties. If you're coming from Java, closures might seem a little strange at first. However, once you wrap your head around them, it'll be hard to go back to a language that doesn't use them. Maps and properties use ideas that might be familiar, but the syntax and usage is different enough that it's worth studying them closely. Grails uses these three things ALL THE TIME, all throughout the framework. For a good example, examine the "BeanBuilder" that instantiates the Spring beans defined in resources.groovy. Also, run through the Groovy documentation at groovy.codehaus.org. A couple of hours there will save you DAYS down the road.
MVC programming. The "MVC" model in Grails pretty closely matches the one used in Rails, but it's significantly different than the "MVC" model used in Java desktop applications. Basically, all incoming URL requests are a message to a controller, which returns a view. Domain objects are the data that you want to store, view, and manipulate through views and controllers. Do an input form that validates the user's input using constraints, and then manipulates it somehow using a controller. Something like a page that takes in your birthday, and returns your Zodiac sign and Chinese Zodiac animal. See if you can get it to return errors to the user when bad input is given.
GORM. GORM is super-important, but you'll be forced to learn it with virtually any project you pick. Give the documentation a once-over, just so you know what its' capabilities are.
Filters and Services. These are "the grails way" to do a lot of DRY programming. Authentication is a canonical example, and it's perfect for learning filters. For services, write something that will send out email. There's a great example of a simple emailer service on the Grails website.
Groovy Server Pages. If you've worked with a templating engine before, then this should seem familiar. Get to know the GSP tag library, it's a huge help. Practical examples include: virtually anything. Every application needs a front-end. Try and make it pretty. NOTE: This spills into a lot of stuff that isn't Grails-specific, like JavaScript, CSS, etc. Unless you have that knowledge already, prepare for a bit of a learning curve.
Your "conf" directory. Get to know every file in there, especially UrlMappings.groovy. Play with UrlMappings so that you have an app that takes meaningful information from the URL. Something like /myapp/calculate/36/times/145, where the app returns an answer.
I'd say those are the basics, but there's a lot of other topics like webflows, i18n, testing, session handling, and so on. The best way to learn those is by building a decent sized project. While you're doing that, you'll probably find yourself thinking, "Gosh, I wish that Grails did ____". Read through the excellent documentation on Grails.org, and you'll probably find a built-in capability or plugin that does what you want. The reference PDF lives on my desktop, and I've found it invaluable during my learning experience.
Oh, and look at the scaffolding code that Grails generates. You'll probably end up pitching it all out, but it'll give you a good idea of how the system works.
Have fun, and happy hacking!
Step 1 - Learn Groovy
If you already know Java, I highly recommend Programming Groovy. It's a lot more concise and up-to-date than the otherwise excellent Groovy in Action. Neither of these books cover the significant language changes in Groovy 1.6, so you should also read this page.
Step 2 - Learn Grails
The Definitive Guide to Grails is probably the standard Grails reference - make sure you get the second edition. Grails in Action is slightly more recent, but I haven't read it so can't comment further on it. I found TDGTG a little lighton GORM, so you might also consider checking out Grails Persistence with GORM and GSQL. It's a very short book, but worth it's weight in gold.
Step 3 - Dive In
Try and modify the sample app in the Grails book, or build your own from scratch. The Groovy console is a great way to experiment with snippets of Groovy code.
If the audience is not familiar with programming in Groovy there should be an introduction to that. Java will work but it gets the juices going when you see how less verbose the code is in Groovy. When discussing GORM include constraints and how they influence validation. Scaffolding is a real time saver when starting a new project so be sure to include it. One of the features of Grails that really has helped me is Plug-ins. Pick a few and show how they provide solutions while saving development time. A security plug-in would fit right into the filter topic you mention. Testing, can there ever be enough testing?
I would really recommend reading the Definite Guide to Grails, Second Edition. It covers everything you need to know about writing applications in Grails. It probably lacks the "what happens under the hood" knowledge, but you should get the hang of it. You can buy it as a PDF and start reading it immediately.
You should also have a list of plug-ins to use - Grails has some really nice ones that come in handy. I can tell you some of the ones I use, but that may be a good question here, too. :-)