I am currently a front end developer. I know HTML and CSS pretty well, I'm OK with jQuery and know some Vanilla JS. I have an idea for a website I want to create where I will be storing data for products (data that I will be grabbing from various websites around the web). It's basically a help me choose application where the user will go through some steps and be given some choices based on their selections. This site is nothing new, but it's more for learning purposes/portfolio work.
Most of my co-workers use ASP.NET and I've seen that you can setup a website like this using ASP.NET and the provided server controls along with C#, however, I want to take another route that allows me to do the same thing NOT using ASP.NET (C# is OK and preferred if that is possible) in that I can grab data, store data, and bind data to my page.
In addition to this, I would like to do this on the Mac.
Here's a list of things I have looked at:
MongoDB (I was really confused by the setup and didn't read anywhere that this would definitely be the solution).
AngularJS
EmberJS
BackboneJS
Several other JS frameworks
Ruby on Rails
Note about the above: Some of the above might be the solution, but I don't want to start spending time learning them only to realize a week in that this is not going to help me get to my goal.
If this post would be better suited for another stack site please let me know. Thank you.
To create a basic website with a persistence you'll need to deal with three parts the front-end (client), back-end (server) and the persistence (database). Of the things that you've listed Angular, Ember and Backbone are all front-end frameworks. They each have their own way of approaching the issue but they all work in the client facing part of the project so views, interaction and dispatching data to the backend. Rails is the only thing that you've listed that's a back-end framework, another option for the back-end if you're more familiar with JS might be Node and Express. Node allows you to build a server in JS and Express is one of the more popular Node frameworks. That section will be responsible for getting the calls for data and calls with data from the front-end and dispatching the appropriate response. Rails typically works with with a SQL database like MySQL or PostGres out of the box because Rails' active record is meant to work with SQL. Mongo is a NoSQL database and I think people are getting it working with Rails but I don't know that it's highly common. Mongo's shell is pretty much javascript and it stores data as JSON (not technically but close enough) so it's been a comfortable choice for JS developers learning back-end. Either Rails or Node can get a server up and running locally on your machine so you can work with the full architecture. So what it comes down to really is picking one of each from those sections and making them play nicely together. For your purposes I would think that the way to go would be either a basic Rails app (probably with MySQL) and using jQuery ajax calls to manage some calls from the front-end or building something with the so-called MEAN stack (Mongo, Express, Angular, Node) which is all JS and using Angulars built in http functionality to handle those calls. Hope this at least narrowed the field of research a bit. Really thats a pretty open question and there are a lot of options.
What is your webhosting site? I suggestPhpmyadmin Or Mysqldatabase You can create tables and strings where you can put the websites you wanna "grab" data from and put a little javascript in there to tell your website if blahblahnlah =blahblahblah then get id="website1"
Some clarifications:
At first, you need to distinguish between a server side language (used to program the functionality) and a database (used to store data).
C# is a language of the .net framework. Regarding websites, there's no C# without ASP.net.
There are two major groups for realizing back end solutions: PHP (market share ~ 40%) and ASP (~ 25%). PHP is a programming language, ASP.net incorporates several programming languages (mainly C# and VB.net).
Both worlds are able to connect to databases: For PHP, this is mainly MySQL, for ASP.net it is mostly Microsoft SQL server.
Related
We have software developers (PHP, SQL) and web designers (HTML, CSS, JS, Foundation, Bootstrap) in our team.
A typical scenario: a software developer implements the business logic while the design is done by another person.
Problem: whenever there are changes in the frontend design, the designers have to send new designs to developers, they have to track changes and modify the sources.
Question: what tools/approaches are available to allow designers to work with the Twig templates directly, and apply changes to HTML/CSS/JS without backend developer help (without Symfony and LAMP installation, if possible)?
Or on a higher level - what is the best practice to separate backend and frontend development in Symfony 2?
Or on a higher level - what is the best practice to separate backend
and frontend development?
The frontend team, can work in the templates and send you the markups and then the backend developers will decorate it with the data, that is how it is usually done.
BUT:
The best approach that you can take to separate totally the 'Backend' work from the 'Frontend' work is doing it. :
Create your backend logic to serve the data at demand (Web service / API), instead of serving the views, send a response with a clean body that contains only the data in a readable format, like json objects.
Then the frontend developers can make the corresponding request to the web service to get the data and decorate their templates with it.
The only thing that you need to do is to provide them with the URL that will provide the data for the template that they are working, and the expected output/format that they will be receiving when requesting that url, so they do not even need any server working, they can mock your response while they are testing / creating the view.
Personal opinion:
I think that even for simple applications, this approach is great.
Why?
If you create your backend as a Web Service / API, then it would be easy to expand it, at some point your application would be used by third parties applications, or you just want to create a native mobile application version, or whatever. If that is the case you don't need to re write nothing.
Short History
I've seen huge proyects that were supposed to serve a web page, then it become populars and it ended with more usage from third parties than the web itself and were not prepared for that. They ended developing a web service, with half of the functionality for the third parties apps, and for each functionality that they added to the web service layer they used more code, more testing, and so on..
Come on, still writing?
Talking about web development, you can keep your frontend guys focused on display the data, style, and events of the page, while the backend guys keep focused in adding new features, so no one needs to distract the other side team just because they don't know how a tool from one side works, that for me worth the time that is saved.
The only "best practice" that I could recommend is to talk with the web designers and understand their needs.
Because TWIG is almost pure HTML
This is just plain wrong. TWIG may look like HTML but it's all about the data. Ask your designers if they would be happy seeing something like this in the browser instead of actual data:
List of Products
{% for product in products %}
{% endfor %}
Somehow I just don't think that will work for them.
I suppose there might be a tool out there somewhere that can convert TWIG into real HTML but what to use as data? If it does not match the back end data then problems will ensue.
I would suggest that you will need to teach your developers how to use composer update as well as your source control system. The database should not be a problem. You can have a single designer database somewhere that the back end folks can keep up to date. Someone else can install and configure the LAMP stack,
You could even setup virtual designer machines (perhaps with vagrant) that will be fully loaded with whatever software your designers needs for a specific project. Your developers might find these virtual machines useful as well.
The other approach is the nuclear option. Don't use TWIG. Your back end turns into a web api and only deals with data. No back end generated html at all. Your designers now have complete control over the front end. Bit radical perhaps but it does seem to be the way the industry is moving towards.
Twig is related to Symfony controllers for the "data".
If your designers wants to modify a html part of the twig templates, they can do directly into templates.
If they want to add additional elements which are related to specific data, the should work with backend developers in order to update controllers code and populate this data from backend to front-end part.
If you use symfony to provide only data (JSON based on lot of AJAX Requests from front-end) I think that designers can work alone with interface and mock JSON data in their local installations without using symfony code.
There is no "best practice" to separate backend and frontend development in Symfony 2, simply because it uses the MVC pattern, which in itself separates buisiness logic from views. All your views are gathered in a single directory, and the only job your designers will have is to display the data. Controlers and all the backend stuff is gathered some place else and is invisible to them.
Symfony is not an obligation (although it is the perfect tool for what you want to do right here), but I'd recommend you choose a framework that implements the MVC pattern, because it is the cleanest way to develop, and assures your code to be maintanable a long time from now.
I will share our solution/practice out of PHP, which completely separate the front-end works from the back-end and our designers and developers are separated in different departments, they are connected by redmine's tickets, but they do not need to communicate to each other in most cases, and also their work will not interact with others in most cases.
Out solution is based on java/javascript, simply we developed our own framework to combat with the issue about separating front from back. Currently we have two independent frameworks for this issue, one is for server side rendering by Java, another one is for client side rendering/binding by javascript, a client javascript MVVM framework.
At first, the basic idea of our frameworks is separating all the template rendering logic from the html template, thus our html templates are real pure html files, without any back-end intrusion.
The second step, our designers will complete their works on the independent html files without any consideration of back-end logic. Then at the same time, our back-end guys will write the back-end rendering/logic by separated java/js source.
Assume we have a html file like following:
<div><input name="name"></div>
<div><span id="name-preview"></span></div>
We will perform the server side rendering by java as following:
Render.create()
.add("[name=name]", "value", user.name)
.add("#name-preview", user.name);
Also we can perform the client 2-way binding by javascript as following:
Aj.init(function($scope){
$scope.data = {};
$scope.snippet("body").bind($scope.data, {
name:[
Aj.form({name: "name"}), //bind the $scope.data.name to input[name=name] in 2-way
"#name-preview" //bind the $scope.data.name to #name-preview in 1-way
]
});
});
As in the above examples, we use common css selector to describe where and how we want to render/bind our values to.
At a matter of fact, in our practice, over than 90% front-end refactoring would not need the help from back-end side. Even in the left 10% cases that our back-end guys have to fix the broken rendering/binding, the fixing would become very simple because we just need to change the target css selectors in most situations.
At last, although we implement our server side framework by Java, we believe it can be ported to any other languages such as PHP, ruby, python, etc.
The server side framework:
https://github.com/astamuse/asta4d
The client side framework:
https://github.com/astamuse/asta4js
Effort:
I am building a word game based on a chat web-client where I need to make a server call on input chat text to validate it before broadcasting on the chat.
I am aware of Meteor providing latency compensation out of the box. But given its still in "early preview" makes me seek other alternatives.
What I tried:
Unfortunately my web search for "latency compensation framework library" doesn't yield anything other than Meteor (including non-personalized results).
Question: Are there any other alternatives that provide latency compensation -or- can make the job easier? I am hoping other developers might have encountered something useful/relevant.
Although Meteor is in 'early preview', its code is very close production ready and a lot of startups and other early adopters are using it for production-level code. You aren't going to find anything that gives you wings like Meteor because no such alternative exists.
As a hardcore Meteor convert and someone who's used many other frameworks, I recommend you to just try Meteor out. As they say, it only takes a weekend for you to build an app in Meteor and decide whether it's right for you.
Having said that, I will attempt to answer the question and list the distant-second alternatives to Meteor that you probably won't want to use:
Derby
Sails
What you're seeing right now in the various real-time full-stack Javascript web frameworks is the future of Web development, cutting down dozens of people and thousands of man-hours of work needed to develop a software project. There are some fast boats sailing that are leaving server-side rendering behind, and you should probably just get in one of them and get going.
RethinkDB uses term 'latency compensation'.
I've also tried to gather per-feature alternatives to Meteor
Meteor is a really cool framework. you can build the complex data driven application very easily using meteor.
But, this framework currently supports only the MongoDB as back-end database.
I have recently created full stack framework called Nooljs which is similar to the Meteor. Now I have open sourced it. It support all the database connections including MySql, ms-sql, and MongoDB. The complex data driven application can be created easily using this framework.
This has been developed using well known existing framework such as Angularjs, Node, express-js, and socket-io.
Easy to build complex data driven JavaScript applications with minimum coding.
Support multiple data connections suck as Ms-sql, MySQL, PostgreSQL, and Mondodb.
Real time framework build top of Express-js and Socket-io
The client side is powered by the Angularjs.
The layout can be build using the Angularjs tags and elements.
Modularized layout to simplify the complex web pages.
Can be mixed both Express-js and Socket-io
I'm running a large classic-asp site (self-developed) for a public library (25k users) which actually performs really good (oracle 11g r2 database), but from time to time new services need to be added or old ones adapted.
And there's my dilemma. Every time I work on this site I feel like I should not update this outdated monster no more and that I should port it to a up to date technology. But how to start? I have good knowledge in developing asp.net (vb.net) websites and I’m searching for a way to rewrite code in .net (Webforms, MVC, WebApi, ... ?) and integrate it part by part into the classic asp site, (I can't rewrite the whole thing at once, because I haven't enough time!) so that some time from now on the site will be completely rewritten.
Another thing I need to consider is the Oracle DB and the already existing and optimized (and often oracle specific) SQL statements that I definitely want to use in the new built (so entity framework and linq seems not an option).
I was thinking about using the new WebApi and call the actions via jQuery from the classic asp site, but couldn't find an easy way to interact it with ODP (returning and accepting Json).
I'm really hoping for anyone to point me into the right direction!
If possible you will need to break your existing website into modules can be separated out and rewritten individually.
Because you are doing such a massive rework between an outdated technology (classic ASP) and bleeding edge (WebAPI etc), it probably won't be possible to run the two as a single application. You will instead have to run two separate applications side by side which will behave as a single application for the user. Part by part you will move your separated modules from the old application to the new.
If you want to continue using Oracle, it's still possible to use Linq and Entity Framework as these are used for querying your data rather than actually storing it. You can use Oracle, MSSQL or even one of the newer document databases such as Mongo or Raven DB.
I am taking part in Imagine Cup and got only three months for building a site in ASP.NET. Is it possible to learn enough to build a working site containing an cms, login system in a month. Its not that I am beginning web development, I already know a little asp.net and know AJAX, JAVASCRIPT, CSS, HTML, SQL but have never worked with databases. I was never into web development but started because of Imagine cup. In 2 months I already know HTML, CSS, JAVASCRIPT, HTML and AJAX but I am worried about the complexity of server-side scripting and ask for the best way to get me working in ASP.NET in a month. I know c#.
Although you can't be an expert in a month, you can get up and running fairly quickly with webforms. Since it already includes a login system, you can get that up and running quickly.
As far as CMS, it depends what you need. An advanced CMS system is a major undertaking.
Getting going with ASP.NET
Actually, if you want to re-apply everything you know about creating JS enabled static html sites, you'd have a smoother path using MVC because you don't have to guess what the tag id's are, you don't have to guess what kind of HTML a server side control is going to create, etc.
That said, Jonathan Wood is correct, to just create a page with labels and buttons, Web Forms has fewer concepts you need to learn, but you will find it harder to apply the same techniques that work well with JS + static html.
Data bases
If you use SQL Compact, then it is easier to get started because you needn't learn to mess with the numerous things going on with SQL Server (like a security model appropriate for big companies, but not for learners). Another easy alternative is MS-Access because the "Query by Example (QBE)" query designer is still better than anything that the Visual Studio or SSMS teams ever put together.
Keep in mind that if you use MS-Access, while it will be really easy to learn (more so than SQL Compact), MS-Access uses Jet SQL and has many other differences from SQL Server, where as everything you learn about SQL Compact will apply to SQL Server.
Not sure what the conditions etc of Imagine cup are, but I strongly recommend to use an existing CMS (in particular Umbraco) instead of developing all from scratch. Some advantages are:
No need to dive into SQL and databases right away
Building blocks are available (login system) and leverage existing ASP.NET technologies
Razor can be used instead of xslt which will be a skill you'll be able to apply to pure ASP.NET MVC development later on
Very friendly and helpful community if you need some help
Starter kits available - basic web sites can be created easily
By diving into any detail of the CMS, you'll learn a lot (source code available)
You could probably pick up the basics with a few good books. Sam's, Wrox, APress and O'Reilly are great. You can also check http://www.asp.net/get-started for Microsoft's official tutorials.
You can also download the express versions of Visual Studio 2010 and SQL Server. If you want to continue on after the competition I'd strongly recommend you learn database programming on SQL Server 2010 Express. (It'll help you down the road)
Good luck with it.
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
We are not sure yet if we will implement automated testing with the
new one.
Implement automated testing. What's the point in replacing one buggy program with another?
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).