I'm developing a Clojure application, which downloads images from the web and analyzes them for certain criteria.
Whatever this might mean, the important part is, that there will be some quite expensive functions in the app, which take a while until they are processed.
In the end, there will be an API that exposes the app's functionality to a web frontend. This is meant to be a second step though.
Since the app has a lot to do with graphics, it makes sense to visualize the outputs of the functions I'm writing during the development process.
Basically I'm looking for an easy way / environment to archive this.
More precisely: Whenever I created a new function, I want to test it's functionality inside a browser: E.g. plot the output, draw some intermediate steps, maybe create some small interactive scripts, that help me to supervise that the algorithms are doing what I intend to. Note: I don't want to to transform the functions to ClojureScript and let them run in the browser, the browser should be just a "display".
Some approaches that came to my mind:
Writing a little backend-server that exposes all the functions of a namespace. So the front-end could access all these functions simply by sending an ajax request to the server, that includes the function and it's parameters in a string, or maybe better in edn format. The back-end receives the request, calls the requested function and sends back the result whenever the calculation is done. Is there maybe already a project, that does exactly this?
Using a project like "Gorilla Repl" This would be a good option, and maybe I'm going to use it. However, I could not yet figure out if it's mechanism covers a way to interactively influence the rendered outputs. It rather works as a worksheet with static renderings.
How would you guys do this? Any suggestions are appreciated.
I have been working on similar problems and I think that you could use the combination of Lighttable + Clojure + Nerdy-painter (plugin).
Nerdy-painter allows you to display images on Lighttable (IDE). Very useful for data exploration or anything that has to do with graphics/plots.
Disclaimer: I am the author of nerdy-painter, still I think the fastest/elegant solution is the one I described above. All other solutions add (IMHO) too much overhead to the development cycle.
A possibility is to use a Jupyter's clojure kernel to interact with clojure. Jupyter runs in a browser and you can add custom binding to simplify access to the DOM.
Here's a clojure kernel: https://github.com/roryk/clojupyter
Related
This is an open source contributor project for Wikidata's Chronic Pain project.
I would like to create a webpage that :
Have inputboxes where the user select several wikipedia page titles (with suggestions)
Can also take these parameters via the URL
Get items metadata from Wikidata.
Makes a SPARQL request to gather scholarly articles.
Render data from Wikidata and Wikipedia, linking to various wiki pages.
The webpage will be hosted on Wikimedia fundation server. I have access to a linux container as well as a Jupyter Notebook (not sure this one is suitable for this project). It has to be coded in Python 3 since I will use Pywikibot framework to interact with Wikidata.
I'm new to programming so that I don't really know what is the best approach. I heard that it was difficult to code webpages in Python without using a framework like Django. However this page is very simple so that it may not be the most efficient to deploy Django for this ?
NB : your question is bordering on "primarily opinion based" (which doesn't mean it's a bad question by itself but that answers might be more, well, opinions than hard facts).
This being said, "a single interactive page" doesn't mean the server code behind is just loading a static html file and sending it to the client. For example, the main UI part of our product is, technically speaking, "a single interactive page", but this "single" page is full react app and is backed by a dedicated API with a dozen entry points, which the dispatch to a whole load of backend code including database access, celery tasks etc. It would of course be technically possible to code all this with only pure wsgi or even plain old cgi code, but well, it could also be possible to write it directly in C or even assembly and no one would ever consider this a viable solution.
To make a long story short: do not even waste your time trying to code this project with plain wsgi (and let's not talk cgi), you will end up reinventing the squared wheel and everyone will hate you for this (stakeholders because you'll never deliver a robust, working product in due time and budget, and other devs because they'll now have to port the whole darn thing to a stable, mature and maintained framework). Now if Django appears to be overkill for this project there are much lighter frameworks like flask. Actually both are the "industry standard" and safe choices.
Note: I'm a backend (Java) developer by trade and work in Clojure in my spare time, so forgive me for my ignorance.
I'm trying to get my head around Clojurescript and how it could potentially fit in with projects I'm working on, or plan to work on in the future. As I've grown up with the "classic" web development mindset (e.g. Clojure running the backend, distributing data to the frontend via JSON to be processed in JS or returning a HTML page for the browser to render), I'm having trouble trying to understand how Clojurescript might make things better than this model.
Could anyone explain to me what the general approach to Clojurescript/Clojure development would be, seeing as the "Clojurescript One" project moniker signifies that application development will be unified under one language (as such)
What tasks would normally be done in the Clojurescript portion of the application?
What tasks would normally be done in the Clojure (e.g. backend) portion of the application?
Any help would be appreciated, or if anyone can point me towards some diagrams or explanations or anything - that would be great too!
I think Clojure/ClojureScript applications will be structured very similarly to X backend technology + JavaScript.
One big benefit with architecting applications with Clojure and ClojureScript - a richer data format than JSON (you can represent hash-maps and sets with arbitrary keys) without losing compactness.
JavaScript is a fine, fine language but ClojureScript offers quite a few benefits. It's semantically simpler (functional), ships with a rich standard library, a robust battle tested application library (Google Closure), and all the benefits you get from the tasteful application of syntactic abstraction via macros.
That said, it's still very much alpha software and the tooling still needs a lot of work.
A bit of background about me, I have developed with Clojurescript, JQuery, Vaadin, Servlets, JSP, and many other web technologies.
1) Clojurescript is much harder to learn than any other web technology I have used as you need, Java, Clojure, Closure (with an s ;), Closure Lib, and Closurescript specific knowledge.
2) Clojurescript doesn't make sense for a small app. It only makes sense when you will have ALOT of client side processing
3) Clojurescript's only use as far as I see is as a better javascript (which is why it is better suited to larger apps) as the minifier part of Clojurescript is available for javascript too
4) Only the client end would be written in Javascript, the server would be in Clojure/Java servlets
Maybe Ganelon micro-framework (which incidentally I am author of) will suit your needs - the execution model is similiar to Vaadin's: server-side Clojure code pushes UI updates to the browser through AJAX/JavaScript, but we don't store application state in session by default.
The demo and docs are available at http://ganelon.tomeklipski.com/
For me, clojure and clojurescript offers cleaner code than mixed stack. There is only one language to think of and code is quite easy to read.
At the backend clojure does things that java usually would do. Input validation, saving to database and above all, implementing business logic. Our backend also validates incoming / outgoing data by types using prismatic schemas.
Frontend in short: We get pretty code using ClojureScript and it is fast to write. We are using ClojureScript version of material-ui when writing UI components. We have to write less code when compared to the JavaScript and I find our UI component code to be easier to read than JavaScript counterpart. One of the main reasons is shorter closing tags and less noise by coding language. Development with ClojureScript is quite fast.
Of course ClojureScript is used for simple imput validation like RegExp for phone numbers etc.
One of the disadvantages of clojure which you have probably noticed is long lines after giving proper names to the functions. I havent found silver bullet how to cope with that.
As dnolen said: ClojureScript is still developing. It is way better now than it was 6 months ago, so you'll have to keep checking its maturity now and then.
I am going to pick up a task that no one has ever attempted to try at my workplace. It is a CF app first written using CF 2.0 (Yes, 2.0!) 10 yrs ago with > 10 cfscheduler tasks.. We explored the idea of rewriting the app, but 10 yrs of work simply can't be rewrote in 2-3 months.
What steps shall one take to modernize the app into a maintainable, extendable state? The one that I keep hearing is "write tests", but how can I write tests when it wasn't even in MVC?
Any advice would be appreciated, thanks!
p.s. I should thank Allaire, Macromedia and Adobe for keeping CF so freaking backward compatible all the way back to 2.0!
btw, what's the most modern, maintainable state for a CF app without MVC framework? or should my end goal be ultimately refactoring it into a MVC app?? I can't image how many links I will break if I do... seems impossible... thought?
update: found 2 related Q's...
https://softwareengineering.stackexchange.com/questions/6395/how-do-you-dive-into-large-code-bases
https://softwareengineering.stackexchange.com/questions/29788/how-do-you-dive-into-a-big-ball-of-mud
I am not sure if you need to move the whole site to a MVC application. Recently I did helped with an site that was not MVC, that still had a library with the Models, Services and Assemblers in a clean and organized manor. It worked great, and we didn't need to do anything more than what was necessary.
That being said, my first step would be to organize the spaghetti code into their different purposes. It may be hard to properly create the models, but at the very least you could break out the services like functions from the pages. With that done, it should be a lot cleaner already.
Then, I would try to take the repeated code and put them into custom tags. It will make the code more reusable, and easier to read.
Good Luck!
Consider, whether a full fledged framework is really necessary. In its most basic form a framework is merely highly organized code. So if procedural, that is well organized, works leave it.
Keep in mind something like FW/1 as migration path can be better than say Coldbox if you don't need all the other stuff.
Lastly, consider this I was able to migrate a 4.5 almost 70% of the way to Coldbox (very simple and really more about directory and file organization versus IOC, plugins, modules, etc...) just using a few extra lines per file plus onMissingMethod functions.
Good Luck.
I had to deal with a similar situation for about two years at my last job, however, it wasn't quite as old as yours. I think I was dealing with code from 4.0 on. There's no silver bullet here, and you'll need to be careful that you don't get too caught up in re-factoring the code and costing your company tons of money in the process. If the app works as it is rewriting it would be a pretty big wast of money.
What I did was update small chunks at a time, I wouldn't even refactor whole templates at a time, just small portions of one at a time. If I saw a particular ugly loop, or nested if statements I'd try to clean it up the best I could. If the app can be broken down into smaller modules or areas of functionality and you have the extra time you can try to clean up the code a module at a time.
A good practice I heard from the Hearding Code podcast is create a testing harness template that would use a particular cfm page that has a known output that you can re-run to make sure that it still has the same output once you've done refactoring. Its not nearly as granular as a unit test, but its something and something is almost always better than nothing, right?
I suspect that the reason this app hasn't been touched for years is because for the most part it works. So the old adage "if it ain't broken don't fix it" probably applies; However, code can always be improved :)
The first thing I'd do is switch to Application.cfc and add some good error logging. That way you may find out about things that need to be fixed, and also if you do make changes you're know if they break anything else.
The next thing I'd do is before you change any code is use selenium to create some tests - it can be used as a FireFox plugin and will record what you do. It's really good for testing legacy apps without much work on your part.
Chances are that you won't have much if any protection from SQL injection attacks so you will want to add cfqueryparam to everything!!
After that I'd be looking for duplicated code - eliminating duplicate code is going to make maintenance easier.
Good luck!
Funnily enough, I'm currently involved in converting an old CF app into an MVC3 application.
Now this isn't CF2, it was updated as recently as a year ago so all of this may not apply at all to your scenario, apologies if this is the case.
The main thing I had to do consolidate the mixed up CFQuerys and their calls into logical units of code that I could then start porting in functionality either to C# or JavaScript.
Thankfully this was a very simple application, the majority of the logic was called on a database using the DWR Ajax library; that which wasn't was mostly consolidated in a functions.cfm file.
Obviously a lot of that behavior doesn't need to be replicated as packaging up the separate components of logic (such as they were) in the CF app did map quite neatly to the various Partial Views and Editor Templates that I envisaged in the MVC application.
After that, it was simply a case of, page by page, finding out which logic was called when, what it relied upon that then finally creating a series of UML class and sequence diagrams.
Honestly though, I think I gained the most ground when I simply hit File-New Project and started trying to replicate the behavior of the app from the top of index.cfm.
I would break logical parts of the app into CFC's
Pick a single view, look at the logic within. Move that out to a CFC and invoke it.
Keep doing that you will have something much easier to work with that can be plugged into an MVC later. Its almost no work to do this, just copy and paste sections of code and call them.
You can consider using object factory to layer your application. We have similar situation at work and we started refactoring by putting Lightwire DI framework.
First we migrated all the sql statement into gateways, then we started using services and take a lot of code out of the templates to the services.
The work is not finished yet but the application is looking better already.
For large, really complex applications I'd prefer ColdBox for a re-factor project. However, I just saw a presentation at the D2W Conference on F/W 1 (Framework One), a VERY simple ColdFusion MVC framework. Check out code from the presentation here.
It's 1 (one) CFC file and a set of conventions for organizing your code. I highly recommend evaluating it for your project.
Currently I'm working with ASP.NET 2.0, which may explain why I'm not as up on this as I might be. However, I don't see a full solution in my Googling of ASP.NET MVC, etc.
Here's my background thinking.
Firstly, data-bound templates are really useful. I'm currently dealing with lots of legacy code whereby people are building up controls programmatically, both on the client and the server, and it's a huge pain.
Secondly, sometimes you want controls to be data-bound on the client, sometimes on the server. The most obvious case for databinding on the server is where you're trying to account for people turning off javascript. But issues of speed, caching, bandwidth etc. all play their part as to deciding where to bind.
Now, on the server I can write UserControls with databinding points. And on the client I can write templates and bind them with JQuery (I'm currently using the microtemplating engine by John Resig as amended by Rick Strahl). But ideally there should be a way to write a template once and let the plumbing make it available for both server and client-side data binding. I guess that XML/XSLT would be one approach to this, but a horrible one. So what else is there? It needn't be an ASP.NET 2.0 solution; I'd just like to think that somewhere there is a fix.
HAML
You can create "datasource" objects that are independent of our databound controls / templates.
To use them with your databound control, instead of attaching them declaratively, e.g.:
<asp:gridview ...datasource="myDataSource"...>
you can attach them with code:
(some event)
me.Gridview1.datasource = "myXMLDataSource"
---or---
me.Gridview1.datasource = "mySQLDataSource"
If you set the datasources up ahead of time (either in the .aspx or in the code-behind is OK), then in this way, you can switch datasources based on some event, or logic, when you want to, without having to re-code / re-publish anything.
Is there a relatively easy way to display the output of a C++ program on a webpage? And I don't mean manually, in other words, you see it on a webpage as it runs not as in I make a code tag and write it in myself.
EDIT: Just so everybody can get this clear I am going to post this up here. I am NOT trying to make a webpage in C++. Please excuse me if this sounds spiteful or anything but I am getting a lot of answers relating to that.
Step one, get yourself a server-side language. Be that PHP, ASP, Python, Ruby, whatever. Get it set up so you can serve it.
Step two, find your language's exec equivalent. Practically all of them have them. It'll let you run a command as if it were from the command line, usually with arguments and capture the output. Here's PHP's:
http://php.net/manual/en/function.exec.php
Of course, if you're passing user-input as arguments, sanitise!
I've just seen that you accepted Scott's answer. I usually wouldn't chase up a SO thread so persistently but I fear you're about to make a mistake that you'll come to regret down the line. Giving direct access to your program and its own built-in server is a terrible idea for two reasons:
You waste a day implementing this built-in server and then getting it to persist and testing it
More importantly, you've just opened up another attack vector into your server. When it comes to security, keep it simple.
You're far better having your C++ app running behind another (mature) server side language as all the work is done for you and it can filter the input to keep things safe.
You could write a CGI app in C++, or you could use an existing web server language to execute the command and send the output to the client.
You want to use Witty.
Wt (pronounced 'witty') is a C++
library for developing interactive web
applications.
The API is widget-centric and similar
to desktop GUI APIs. To the developer,
it offers complete abstraction of any
web-specific implementation details,
including event handling, graphics
support, graceful degradation (or
progressive enhancement), and pretty
URLs.
Unlike many page-based frameworks, Wt
was designed for creating stateful
applications that are at the same time
highly interactive (leveraging
techinques such as AJAX to their
fullest) and accessible (supporting
plain HTML browsers), using automatic
graceful degradation or progressive
enhancement.
The library comes with an application
server that acts as a stand-alone web
server or integrates through FastCGI
with other web servers.
I am not sure this is what you are looking for but you may want CGI You may want to look at this SO question, C++ may not be the best language for what you want to do.
based off the questions you posted Writing a web app like what you want is no simple task. What I would recommend is use some other library (this is one i found with a quick google) to get a web console on your server and give the user it is running under execute deny permissions on every folder except the folder you have your app installed.
This is still is a risky method if you don't set up the security correctly but it is the easiest solution without digging around too much on existing libraries to just have the application interactive.
EDIT --
The "Best" solution is learn AJAX and have your program post its own pages with it but like I said, it will not be easy.
It sounds like you want something like a telnet session embedded in a webpage. A quick google turns up many Java telnet apps, though I'm not qualified to evaluate which would be most ideal to embed in html.
You would set up the login script on the host machine to run your c++ app and the user would interact with it through the shell window. Note though that this will only work for pure command line apps. If you want to use a GUI app in this way, then you should look into remote desktop software or VNC.
It may be worth looking into Adobe's "Alchemy" project on Adobe Labs
This may help you with what you're trying to achieve.
:)
Are you looking for something like what codepad.org does? I believe they explain how they did it here.
There is a library called C++ Server Pages - Poco. I used it for one of my college project, its pretty good. There is also good documentation to get started with, u can find it here http://pocoproject.org/docs/