Related
I wrote an application in a JS-based framework called Titanium. This framework doesn't have some functions, so I'm bundling autohotkeys, and using STDIN/STDOUT to connect the two. Autohotkeys has a cool function DllCall which allows to interconect with the operating system and should help me close the gap between the JS-based framework and the missing functionality.
To give you an example, Titanium allows me to bind to a specific port. But if I bind to 0 and let the OS pick a free port (as it should), it will work, but there's no way to tell which port it actually bound to.
Now since I come from web applications, DLLs are new to me; so I have a few questions:
Is there like a big doc with all the DLLs and all their methods?
How do I know if some methods are dependent on some services? I mean I've heard some rely on RPCs, COM, COM+, WMIs, etc. which a user can turn off and if it does, these methods won't work. Is there also a place where I can get more info on this?
Are there any off-the-shelf DLLs, with their methods, which I can trust that they will work 100% from XP up to 7?
Are there any access permissions I should know about? Are they documented.
If you also come from web programming, is there anything else I should be aware about?
Thank you very much.
You can find a (mostly) complete documentation of all Windows API functions (which reside in DLLs) either online on MSDN or offline using the documentation from the Windows SDK.
For example look at the documentation for SHGetSpecialFolderPath. There you can find various information, like the DLL (shell32.dll), any prerequisites (min. IE 4) and the platform availablity. (min. Windows 2000) Also security considerations are documented.
All API functions are documented more or less in this manner. A good starting point is the Windows Developer Reference. From there you can browse through the many API functions.
Basically the answer to every question is that you should search MSDN for the functions or APIs you are interested in and read the documentation there:
http://msdn.microsoft.com/en-us/library/ms123401.aspx
They document which operating systems the functions are available in so it should be easy to write something that works in Windows XP and up.
I know this question is too wide to be answered with a simple "use this framework", but I would really appreciate your advice on that one.
I'm looking to make a (quite complex) project than will run over an API. I'm open to any programming language (PHP, Python, Java mostly) and found many frameworks that are more oriented to make a RESTful web server.
The only major constraint I have is that I would have a reusable, simple and not-code-spaghetti independent package in order to improve my API later easily or even switch to an other framework with no pain.
For Python & Java, I thought about making a dedicated package. Each action would call the dedicated method in the package, the package would return object/dict and the action would transform it to the proper format.
After many research, I hesitate between two framework that could be good for my work but I need your advice because I wouldn't make any mistakes here.
Play! Framework (Java)
Pros :
Router are RESTFul oriented (you define the method (GET, POST, etc), the request and the class.method to use)
You don't have to make one class per action
Cons :
The Model is already included. If I later change the framework, maybe I will be stuck with it (but apparently not since Play! seems to use JPA)
Maybe the fact that if I want to send parameters to the action that would be defined in the method signature, I have to adopt the ClassName.properties instead of a json like {ClassName: {properties: 'value'}}
Tornado Web (Python)
Pros :
Seems to be very powerful : used by FriendFeed (at least) !
Auth via major OpenId, OAuth and Facebook already implemented
Very light (could be a problem)
Cons :
Not so popular : you understand better the work by going into the code than the doc
Urls seems to be very basics (As far as I saw it, you have to define all the urls in one file, with all the class included)
One Class per action (that could be heavy)
Decorators for the basic (testing if user is auth, etc) must be made
For using them in production, it would be easily possible with apache & mod_proxy or nginx.
So, my questions is quite simple : what would you choose (between those two or others, I'm not closed to suggestions) and why ?
Thank you really much for your advice!
My favorite RESTful Web App development framework is Restlet. It's a Java framework/library (it can be thought of as either) but it works well with Jython and JRuby, so if you prefer those languages you could still use it. I mostly use it with Groovy.
I prefer Restlet because:
Its API fully embraces and aligns with RESTful paradigms, so it encourages you to work RESTfully. For example, when a Router routes a request to a ServerResource, it creates a new instance of the ServerResource for every request. This encourages the implementation to be stateless. And there's a rich class hierarchy with all the concepts required to implement a RESTful web app: Client, Server, Protocol, VirtualHost, Request, Response, MediaType, Status, etc.
Its API includes classes for writing both servers and clients, and they're very consistent and almost symmetrical. For example, there's a ServerResource class and a ClientResource class. ServerResource.get() and ClientResource.get() both return a Representation. The only difference is that you implement ServerResource.get() and generate a response representation, while you call ClientResource.get() and receive a response representation.
The API is consistent with Java conventions. For example, if a request made with ClientResource.get() receives an error response such as 401, a ResourceException will be thrown. And if you're implementing a ServerResource and want to return an error status, you just throw a ResourceException (which is a RuntimeException, which is nice).
Via its extension mechanism, it plays very nicely with a broad array of the best Java libraries around. Extensions are included for various HTTP client and server libraries, databases, templating libraries, security libs, data libs such as XML, JSON, OAuth, OData, etc., and even OSGI.
Deployment is very flexible. You can embed a Restlet-powered API in an existing Java app, an existing Java Servlet app, or any standard Java Web App (Servlet) server. Or you can build a stand-alone server app with an embedded HTTP server such as Jetty — that's my preferred approach. And because it runs on the JVM, it runs on almost any hardware or OS.
It's mature, reliable, responsibly maintained, steadily improving, and well supported both by the community and commercially.
It's open source, and has very clear and well-structured code. The developers are happy to accept any contributions. I've submitted a few patches and had them committed to trunk quickly with no drama.
Other options I'd suggest would be the Python microframework Bottle and the Ruby microframework Sinatra. They're both simple, straightforward, lightweight, and effective. And because they work with the WSGI and Rack stacks, there's a rich set of "middleware" modules which can easily be used with them.
Where can I find the code for creating an online rebol console like the one here ?
http://tryrebol.esperconsultancy.nl/
Update: for the sandbox system on the server, can't Rebol manage it itself with some security wrapper and its security options ?
As for console itself, I don't know Ruby so I don't want to use TryRuby and why would I need it ? Can't I mimic Rebol console itself by "remoting" it somehow ? Why RT or Esper Consultancy can't make an opensource version ? There's no value in keeping it closed source. Rebol needs to prove it's more open than in the past.
In my opinion, you should aim higher with something like the already open-sourced Try Ruby. You'd type in expressions and it would guide you. Their showcase site is at tryruby.org and is fairly slick.
I modified TryRuby to work with Rebol and it wound up looking like this:
But I'm not going to run it on my server because I didn't want to belabor the necessary sandboxing/etc. or protections against someone running an infinite loop. I can give you what I've got so far if you want it.
I started a tutorial script here that no one seemed interested in helping me with, so I wandered off to other tasks:
http://www.rebol.net/wiki/Interactive_tutorial_script
I'm not sure what exactly you want. You mention you want a remote REBOL shell instead of a tutoring setup, but that's what the Try REBOL site is. There are several reasons it's not open source:
It's in heavy development. I'm currently changing the code regularly.
So it's not in a release state. Preparing it for release, documenting and publishing it would take a lot of extra work, as with most projects.
It's written in my CMS that's also in heavy development. Even if the Try REBOL site were open source, it wouldn't run. The CMS is not planned to be open sourced soon.
It's not meant as a generic REBOL remoting tool, but as a one-off demo site. If that site is running, what's the use of more of them?
As others have answered, there are many generic solutions for remoting that you could use. Also, most parts of the Try REBOL site are readily available as open source:
Syllable Server, produced and published by us.
The Cheyenne web server.
The HTML source of the web client can be viewed, including my simple JavaScript command service bus.
Syllable Server is an essential part of the site, as the sandboxing is not done with REBOL facilities (except some extra limits in the R3 backend), but with standard Linux facilities.
A truly air tight (do I mean silica tight?) sandbox is close to impossible with R2.
R3 (still in alpha) is looking a lot more promising. The deep technical discussions in flight right now (see Cure code and AltME/REBOL3 Proposals regarding unwinds and protect and even occasionally mentioning sandboxes should lead to an excellent sandbox capability.
Right now, the big advance R3 has that makes Kaj's tryREBOL possible is R3's secure policy settings which make it possible (with some careful wrapper code) to construct an alpha/demo sandbox.
To answer your precise question("where can I find code...", you could try asking Kaj for his :)
I'm new to StackOverflow. I'm not sure if this is going to end up as a reply to your comment, or as a new answer.
The somewhat common idea that any project can be open sourced and contributed to by others is a naive view. In the case of my Try REBOL site, it makes no sense. It's not just in heavy development; it's written in a CMS that's also in heavy development. Basically noone could contribute to it at this point, because I'm the only one who knows my CMS. Or in any case its newest features, which I develop by developing Try REBOL, and other example sites. So developing Try REBOL means developing the CMS at the same time, and by definition, I'm the only one who can do that.
More generally, my projects are bleeding edge, innovative technology with a strong vision. The vision is mine, and to teach it to others, I have to build it to show how I intended it to work. So there's a catch 22: to enable others to contribute, I have to finish my projects first, because people typically don't understand them until I show them how they work.
There certainly are other projects where mass contribution makes more sense. Still, only the top projects get the contributors. We found that out the hard way. We created Syllable Desktop and Syllable Server with surrounding infrastructure for contributions. These are fairly classic, well understood operating systems that many people could work on in parallel. However, despite years of begging, we get very few contributions.
So, if you feel a burning need to contribute to our projects, please pick one of the many tasks in Syllable to execute. :-)
I've been recommended the Click framework from Apache. But I can't find any forums talking about benchmark, reviews, advantages, disavantages, usefulness, ease of implementation, etc.
I've been asked to use it to develop a web site, but I'm completly in the dark about its strengths and weaknesses.
And its damn name isn't helping !! Click ? Hey Apache ! Call your next framework "the" just for fun. I dare you.
So can anyone comment on his experience with Click ?
What I personally like about the Click framework is that it is fairly close to HTML/HTTP and the Servlet API. There is no huge abstraction to get familiar with. You have a Page class, a Form class, ... If you need to preserve state across invocations you put it in the session or you pass it through the URL... This makes it easy to start using it. It is also straightforward to control the HTML pages being generated. It may sound like it is a very basic framework but the simplicity is actually one of it greatest strengths.
Other frameworks (e.g. Seam) are more suitedr to create a very large web application with lots of reusable components and complicated pageflows but the learning curve is much steeper. So for me Click works well for small to medium sized websites.
It's an apache incubator project but that does not mean the project is not stable, rather it reflects that it is in transition to the Apache project model.
Click is Apache's version of a component based web framework equivalent to JSF (other component base Java Frameworks are Tapestry and Wicket)
Click is rated at Ohloh
There is an official blog and some Wikipedia references: Framework Comparision and info page
What are the software/ Wiki you use to write and share your specs about the developers, testers and management?
Do you use Wiki system, and if so, what Wiki software you use?
Or do you use Sharepoint to manage and version the specs? One problem with SharePoint 2003 as specs platform is that it's very hard to collaborate among different people.
For backward compatibility sake, I would also like to have the platform able to import Microsoft Word seamlessly. And it would certainly help if the interface is similar to Microsoft Word.
Any idea?
I've used Confluence at a number of places, it's a pretty powerful wiki and very good for creating specifications that can be shared amongst various parties. See:
http://www.atlassian.com/software/confluence/
There's some more information here on the advantages of using Confluence:
https://stackoverflow.com/questions/170352/confluence-experiences
EDIT: I've updated this to deal with the Microsoft Word import feature you mentioned. Confluence supports this through the Office Connector here:
http://www.atlassian.com/software/confluence/plugins/office-connector.jsp
There's also a Sharepoint connector:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
plus a whole bunch of plugins:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
Some of these are user contributed also. I can't recommend Confluence enough as a commercial wiki.
I've also used JSPWiki, which is open source. it's ok but not as good as confluence, see:
http://www.jspwiki.org/
You could try Google docs - I have successfully used this in the past. It supports import / export to MS Word, and it has great support for multiple user - see http://www.brighthub.com/internet/google/articles/8236.aspx.
It supports versioning, allows you to chat with other people who are currently working on the document, and shows you a list of all the changes others have made to the document (without needing to close / reopen the document).
If you want corporate support, Google also provides that - see Google Apps for business.
We use SharePoint -- it's not ideal, but it does a decent job. If I were you, I would seriously look at getting off SharePoint 2003 and on to MOSS (SharePoint 2007). It's not perfect, but it's substantially better. Here's a little bit on using MOSS as a wiki. I think in general wiki's are a good tool for getting people up to speed on your system. We used to pass around "getting started documents" and now we have all that type of stuff in our developer portal.
Per John's comment, I looked up this feature comparison. I have to go back and look at what features I'm using that are not in WSS -- I might be paying for licenses I don't need! :)
We use email. I know it isn't elaborate, but it is easy to use. Everyone has it installed and there are no licensing issues. All spec changes are sent to an super set email distro indicating the updates and the location on the network share where the spec can be found.
We use Alfresco, in its Community version, from both its Share and Explorer web interfaces.
Quite useful, with a document library, wiki, forum and calendar.
We curently host about 1.8 Go consisting mainly in docs, versionned and sometimes automatically converted to PDF (by creating an automatic content rule).
FTP, WebDav and network share are also used to access to the same repository.
You could take a look at Microsoft Groove - the collaboration software that Microsoft bought a few years back.
It's bundled free with premium versions of Microsoft Office.
You can customize the workspace with discussion boards and can fairly seamlessly store collaboratively-edited Office documents.
We use MediaWiki for dos & specs. Wiki definitely wins anything like Microsoft Word or SharePoint - it allows you to develop a documentation in "first refer, then describe" = "divide and rule" way. Perfect for developers - they used to think the same way. The process of developing a documentation is almost ideal: you start from TOC and drill down until you write the document for every link you put earlier.
MediaWiki is quite customizable - there are lots of extensions there. The most necessary ones are:
Source code highlighter - CSO_Source
Our own templates integrating wiki with class reference.
Others are InterWiki, FileProtocolLinks, YouTube (we use customized version of it to display HD video), ReCaptcha, SpecialDeleteOldRevisions, Maintenance.
Some integration examples are here.
And we use Google issue tracker to track the issues. Its main advantages:
Imput usability: the process of adding\changing the issue is really convenient there. Earlier we tried Track Studio - the same actions require 2-3 times more time there, so it died fast simply because most of us hated to use it.
Customizable grids. See the examples. Really helpful.
Atom\RSS support. So everyone knows what's going on.
There is a Gurtle tool integrating it with TortoiseSVN. Really helpful.
Its main disadvantage is that it can't be closed from the public access. This makes it simply unusable in many cases.
If you want a UI similar to Word, why not use Word with SharePoint 2007? You're on 2003 so the experience is there. Upgrade to SharePoint 2007 and you can have the collaboration, Word features, document sharing, and so on.
This is the kind of thing Microsoft wants people to use Office for, so there's a ton of doco out there about how to configure your SharePoint and Office environment to support collaboration.
There is something that Google do in this direction and it looks really cool: wave.google.com. It would be a great step in collaboration and worth to wait it.
Here we use Google Docs it makes the documents available to everyone write or read only, public or private among people that have or not Google accounts, it also can import Word docs, not to mention that it runs directly into the browser so it has high availability with zero cost and zero setup, also its computer/OS agnostic, we have a nice experience with it.
Also perhaps you should take a look at Basecamp or Backpack at 37Signals, any of then might also fit your bill.
We use DocBook for all of our specifications (and other customer-facing documentation). DocBook is an XML format that lets you easily generate documents in just about any format, including PDF, which is how we distribute things to clients to get them signed off. We can divide a document into files (by section) and commit everything to our source control system (Subversion). Because it is all XML (i.e. text-based), Subversion's automatic merging and conflict resolution works great if two people work on the same file. We have a set of stylesheets that all of our documents use, so all documents share the exact same style/format, with no extra work on our part.
And if you don't like editing XML files directly, there are GUI front-ends that provide a reasonably WYSIWYG-like experience. I believe that most people in my office use XMLMind. Still, we happen to all be technical people so if we had to write XML directly it wouldn't be an issue.
As a sidenote, we also put out release notes. We have some XSLT that lets us write documents like this:
<bugs>
<bug id="1234" component="web">JavaScript error when clicking the Kick Me button</bug>
</bugs>
We then have a script that runs through our Subversion repository doing an svn log from the previous release tag to the current release tag, and some Bugzilla integration to automatically generate release notes on-the-fly.
(also, for most internal-only documentation, we use MediaWiki, which is also a great way to collaborate.)
We use OnTime. It was originally only used for defect tracking, but we've started using it to track features as well. These can be used to document the feature as it evolves during development. Features can be grouped together into sprints or releases, and time can be tracked against each feature. If you are using SCRUM, you can also plot burn-down charts for each sprint. It also has wiki functionality.