Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Recently I did some web design work for a person. I continued to show him progress by giving him a link to his new site on my development server. Nearing the end of completion, he dropped all contact with me and I was completely unable to get a hold of him. I took a look at his site recently, and he mixed a combination of his old site, with the new one I was creating. I thought maybe he redesigned it himself after looking at my version, however a quick look at his source code shows that the parts I recognized were full out just copied by viewing the source code on my dev server. So he completely stiffed me and I received no payment from him.
Just wondering if there's anyway to prevent that in the future?
My first thought was obfuscation, but a quick search shows that doing that to html is not recommended and not foolproof anyway.
Obviously this is a lesson learned for me to get some sort of up front payment first, but being able to prevent work from being so easily stolen in the future would be nice.
Are there any developers that have come across similar issues? How do you show someone the progress of your work without giving them plain as day access to your source?
The other answers here are just a set of hacks that can be undone.
The client side, HTML, CSS, and JS is made up of all open source technologies. While you could spend a lot of time trying to obfuscate your client side code, your best bet is just to practice better business logic.
The options open up widely on protections for server side code but your question seems to focus on client side code.
For well established trustworthy clients I am much more flexible but new clients I am super careful with. I demand progressive payments. For each deliverable there is a payment involved. That way if the relationship is ever severed both parties have what they want.
When you make yourself an easy mark for scammers you only attract scammers.
IMHO a good way would be presentations e.g. with TeamViewer or a similar software when you cannot go to your customer.
You could also provide screenshots or a basic remote access with vnc or so, where you customer can see but not touch the site.
What you could do, is use HTML Image Maps with screenshots to create a basic, interactive version of the final product.
It's possible to encrypt your source code with javascript. Try this website: http://www.iwebtool.com/html_encrypter
I never used this tool myself and I don't know if everything works well, but I think it's worth giving a shot. You can always upload the normal source code after being paid. Also, make sure that you have the right contact information of your client in the future. I also highly recommend using a contract in the future so that your client is legally bonded to pay you. Another possible option is giving your client nothing but a screenshot of the site, but of course your site will become static.
Use a website that have an escrow service, or an escrow-like service, where the employer pays all the money upfront to the website, and it will only be released to the coder after achieving a predefined goal.
Many freelancing websites provides this service.
I've built a tool, which really encrypts your JS-sources - no simple obscurity by obfuscation, but good security by encryption.
See how it works here: http://ec2-176-34-64-10.eu-west-1.compute.amazonaws.com/nopro/xscroll - it's a demo only for hiding the script xscroll.js.
When you inspect the DOM in your client, all you see is: nplreq(url) for each script you bind into HTML head.
Encryption and decryption are totally transparent to the browser. It is tested with Firefox, Chrome, Opera, Konqueror, IE8-10, Dolphin and Safari on an Android tablet.
Encryption with AES (Rijndael 256) using one-shot-keys which are negotiated between client and (liblock-)server using Diffie-Hellman.
The sources are securely hidden, and only with really great efforts they may be reached again.
You could either just run the site on your laptop or put the entire site behind a login page that requires a password. You would be able to do live demos, but the client would not have access to the site until you have been paid.
A passionate discussion from today.
Developer 1: "AJAX is a set of tools,
use it where it really helps, not just
for the sake of it."
Developer 2: "Its almost 2011, we can
build rich desktop like applications
in the browser, we should use AJAX
everywhere and make a single page
application with everything in it an
AJAX powered component."
I can understand things so far. Here's where I don't get it.
Developer 1: "Using AJAX to make a
single page app, we will have to write
our own code to manage bookmarking and
browser back forward buttons"
Developer 2: "No problem, that's
easily doable. It's worth it because
AJAX solves the problems we had with
normal GET/POST, the statelessness.
With a one page AJAX app, you can
maintain context, you don't need
hidden variables, heavy session
management as you would when you moved
between pages"
Is Dev 2 right? Has AJAX really solved problems with how the 'web' normally works?
No.
First of all, there's no problem with how the Web works. It was designed to be stateless, and even with a single page AJAX app, the Web is still stateless.
The problem is with how Developers approach managing state in the stateless environment of the web. Single page AJAX applications definitely make managing state much easier for developers (actually, it sidesteps the problem entirely) that are used to being able to manage state easily in a desktop application.
Just remember, though, that if you have a single page AJAX application and you forget to send the state back to the server for persistence, you lose it...
In my personal opinion, single page AJAX applications also have code management/readability/maintainability issues that far outweigh the state management benefits. I'd rather learn how to properly pass state from page to page in my application that deal with the headache of a single page that contains all of my code.
You answered your own question with: "AJAX is a set of tools, use it where it really helps"
AJAX has solved a lot of problems by streamlining user experience and allowing the developer to control the flow server-side and client-side scripting. There is a development cost to utilizing AJAX to its maximum potential that its viability is dependent on the project, requirements, performance expectations, etc.
Node.js is very likely to revolutionize web development and web scripting as well. If there is a long-term scope to web development projects, keep the cost-benefits of upgrading to future technologies in mind as well.
There is a time and place for everything. Writing web pages to not load a new page AT ALL 90% of the time is not appropriate. Certainly there are exceptions for web applications such as Google Docs etc... but AJAX solves a need, and that is "I only want to update a small portion of my page, I don't need to load the entire page again."
You have to understand the needs of your users with the realization of expectations. If I make a comment, I do not really expect the entire page to load again. It's not necessary. If I want to visit another article on the page then I would expect it to go to a different page entirely.
Do not think of AJAX as an all or nothing solution. It fits specific needs just like traditional web pages do, and the two can be married to perfection if that is understood. Otherwise you end up having to write code for a solution to a problem that does not normally exist.
Situation
I have been working on a project lately where the UI development seems to be way too time consuming. In this case, the "Business Rules" on the server-side are much more complicated than the presentation aspects as far as a Computer Science or complexity perspective.
I've found myself scratching/banging my head against the wall with problems with behaviour that differs from the intuitive approach all the way to being a black hole of time waste and poor documentation, where I might be trying to get a simple UI element to line up correctly.
I'm not complaining; I understand there are complexities and a wide audience to support with web development, but I am perplexed by how long it takes to do what seems should be the easy part compared to how long it takes to write the code with complex logic, math, science, etc.
Question
What are you thoughts and personal experience to go from concept to reality with web development and to do this rapidly, or at least in a way that you can have a sense of how long it might take? I have purposefully not mentioned any frameworks or languages, because I would really like to here what web development stacks you use, what tools or best practices help you get things done faster, and how you end up with code that doesn't feel totally brittle and full of hacks.
Hyperbole, language preferences, and all thoughts welcome, I would at least like to get a sense of what is being used for web development that has a high success rate, even if it isn't the latest and greatest thing around.
I personally have found breaking everything up into small tasks helps.
The way I like to design web pages:
Draw out the design, or photoshop it.
Create the HTML - no CSS, no styling at all
Now add in your style - basic style, like positioning, save making the menu perfect for later
Connect to database if needed / server side code
Now add in any javascript, ajax needed
Tweak it to perfection
If you have all this broken into small tasks, when you get done with each, you feel more motivated to continue working.
Like I said, this is how I do it, and it seems to go quickly, especially since I only get about 1 to 2 hours a night to work.
The answer to this question depends on if you are working alone or leading a group.
If you are leading a group you will want to break apart responsibilities as the following:
Designers - These people should own the creation of graphical mockups and the creation/maintenance of CSS. They should own CSS as a responsibility so that they know not to create outrageous graphical mockups that cannot be created as a webpage without considerable code bloat.
Markup - These people should own the authoring of HTML, accessibility, semantics, RDFa requirements, and any other aspect associated with front end data structure.
UIT - These people should own JavaScript, efficiency requirements, content-management requirements, internal process and front-end tool/process governance, and generally own best practices for all client visible code.
Applications - These people should own server-side application code development, content management system creation/maintenance, and database access requirements. These people are application and services programmers and provide the interface to database and services personnel.
QA - These people test all business requirements of the final product in a certification environment. If errors are seen the bug/ticket should be updated and reassigned. The work is not finished until QA signs off as valid.
Business Owner - The business owner is the person/team responsible for writing the initial project requirements and making a final approving decision about the deployment of the project. This person should have no interface to the technology process outside the drafting of business requirements.
Project Manager - This person ensures that a project is continually moving forward and that milestones are completed in accordance with any deadlines. It is this person and not the business owner that is to interfere with the technology process to ensure things are getting done. This person must act independently of the business owner and must not serve as a tool to the business. The project manager must not own or recommend changes to the requirements to the technology personnel. If changes to the requirements must be made this is a one way process from technology through the project manager to the business owner.
The flow of development should be the following:
1) Designers create the graphic mockup and then reassign the bug/project ticket to the project business owner.
2) Upon business approval the ticket should be reassigned to Markup staff or rejected back to design with specific change requests.
3) Markup writes the HTML and content. Any application or database requirements should be specified by business before the project begins and the Markup team should write code for all possible scenarios. The structure of content should reflect the organization of content on the visual markup completely without regard for presentation. The ticket should be reassigned back to Design for CSS creation.
4) Design writes the CSS to add presentation in compliance with the graphical mockup they created. The design team must have access to the HTML markup to add class attributes as necessary, but should not be allowed to make any other changes. The ticket should be reassigned to Applications to complete all server side requirements.
5) Applications should create all necessary requirements for database access. Ticket should be reassigned to UIT if the prior requirements are satisfactory or reassigned back to Markup for changes/additions.
6) UIT should be the final step to write the JavaScript interactions necessary for user-interface and AJAX requirements. UIT also should proof the prior completed markup for standards conformance, efficiency, and best practices. UIT should quickly reject the project if the work is less the acceptable. If additional Applications work is required reassign to Applications otherwise reassign ticket to QA.
7) QA is the final technology stop. These people test the business and functional requirements of the final product. The project cannot be released to production without QA sign off. If a business requirement fails QA must not sign off. Upon QA sign off the ticket should be reassigned to the business owner.
8) The business owner reviews the project and determines if all requirements are achieved. If changes/additions are required they can be submitted at this time. Changes/additions MUST NOT be submitted earlier, because frequent changes delays all projects. It is the responsibility of the business owner to ensure their initial requirements are complete and specific. If the requirements are not reviewed for fullness it is the fault of the business owner and changes can be submitted at this point. It is because of this responsibility, and other associated business responsibilities, that the business owner deserves to get paid more for being less involved.
That is the most efficient manner to get the job done. Separation of duties is extremely important and adherence to the process is extremely important. If those two things fail the entire process fails and business incurs significantly increased development costs.
If you are acting on your own and not part of a team I would still follow a similar process and push the role business owner onto the client. If the client wants to make changes/additions premature to the project completion then they can pay more money by amending a change addendum to the original requirements contract. You do not loose pay from increased labor because a client cannot make up their damn mind. If that is upsetting then the client can pay even more money for a contract cancellation. This is not mean it is business. If your time is not a valued commodity then you should not be in business as on your own.
I've been using the .NET stack for about 5 years, the ASP.NET MVC stack for about 3 months, and old ASP for 4 about years.
The key to dealing with complexity is mitigating it. In your code, always abstract away complexity to a reasonable level. For example, say there are 10 steps to placing an order. In that case, at a higher level, you would have a method 'SubmitOrder'; under it might be 10 method calls for inserting appropriate records, dealing with inventory and so on. In each of those 'business' layers, you can just deal with these business problem, and even below those layers, you would deal with data and mechanical details. The benefit to all of these layers is that you make each layer deal with a chunk of the work, and as you go up closer to the UI, you have an 'interface' that makes sense to the UI and the way the application needs to flow.
I think you're a little mistaken about UI development. UI development is difficult and usually underestimated in its importance.
There's a need to know the basics - before you jump to HAML, know your HTML so you know what you're abstracting away. Before you jump into jQuery take the time to learn JavaScript basics - you don't need to be a pro, but when you need to add some numbers together you should not go looking for a plugin. Have a good understanding about how to style things with CSS. There's a lot to topics and technologies to learn to be a competent web UI dev.
That said, for greenfield development Rails is pretty sweet. Pick jQuery. And don't choose a platform that hides how the web really works.
I use UI designers. They are excellent for that sort of thing.
I craft my application requirements around what is practical and sometimes easy in terms of front-end work.
My companies does mostly .NET development and we have been successfully using the 'net-tiers' templates for data access layer. The templates are loaded into CodeSmith code generator and pointed against a database. The end result is anything you could possibly think of. It'll generate your DAL, webservice, winforms UI library, web UI library, a sample website and administration tool and more. A great tool to save some development time. Check it out.
As far as actually working on UI, i think it may benefit to actually hire a professional. We have a professional designer who does some contract work with us. All that we do is wire up the UI to our UI components and code.
To speed up getting an HTML page that looks like you want:
First, decide on a design and draw what you want it to look like using a graphics program (if you've got a UI designer they do this step). Then, write static HTML and CSS that matches what you've drawn. Once that's done, write code that outputs HTML that matches the format that you've decided on.
I did this for a pretty complex set of states for a web app, and found that first writing HTML and CSS by hand, without having to wrestle with your server program, makes it go much faster.
The common mistake web developers do most often is that they start writing markup without thinking what they are making and How it will look like. Later when they stuck in any problem then they have to restructure the markup several times which also affect the design too and not an efficient way.
Good developers have habit to design first then develop. What I mean to is it is better to design your website in Photoshop first the start coding. This help them a lot because they knew what they are making and what they can do later as well.
After planning let's talk something about the coding environment. Of we have a nice setup for web development then it will increase our productivity. The major part is Text Editor .It is very important to have a nice Text Editor because we do most of our work on Text Editor. Text Editor plays an important role in increasing our productivity. Well,You can't use notepad or notepad++ in 2019 . They are outdated. The best Editor in 2019 is VSCODE and Sublime Text.
Personally I use sublime Text with some plugins.
Another important part of web development is version control. You can use git for this purpose. There are many online free cloud storages too like github , bitbucket etc. on which we can save our code and access it from any part of the world. Now these days many people are remote workers and to share their work they use git. It is not only helpful in web development but it is also helpful in every software industry. This also allow you to try different styles by simply making branches without messing up with the code.
The least famous but most important part of any software developer or web developer is to use comments while coding because on small project it is very easy to find a particular piece of code but when you are working on large projects or work with a team then comments are necessary because the other developer might not be familiar with your naming conventions. If we use comments then you know what this particular code do.
In last one more thing I would like to suggest for web development is to use browser's developers tool. They are truly awesome and very helpful in finding an error. Developers tools contain console, live code preview, responsive website preview with various mobile devices options and much more.
Some useful plugins for web development are:
Emmet
Prettify
Color Picker
File Icon
Git gutter
Integrated Terminal
Hope you get the answer of your question
Developers are extremely prolific individuals. They are continually improving their tools in order to increase their production and produce better outcomes faster.
For over a decade, I've been doing full-stack web development. One of the most difficult hurdles I'm having right now is that I need to focus on a range of tasks in a short amount of time, from designing user interfaces to deploying web applications.
To speed up my output, I use a number of technologies and frameworks. For UI, I usually use Bootstrap 4 and Bulma for most of my projects when it comes to building responsive web apps.
As I continue to focus on developing a variety of Web applications, I've seen that there are certain similar themes that I've noticed when doing so:
Consider the following example:
User Interface for Login/Signup/Forget Password
Layouts like a dashboard
Layouts for User Profiles
Form of Configuration
The list could go on and on.
I believe that most full-stack developers have come across the same UI pattern when developing their Web Apps UI.
So, to make the above procedure go faster, we created a simple tool that allows you to drag and drop — pre-made Bootstrap 4 components like Signup Form with Cover Image, Login Form, Dashboard Layout, and so on...
But wait, there are already a number of comparable Bootstrap builders out there, so why do I need to create another one?
The majority of Bootstrap Builders are focused on creating websites, however we choose to create this specifically for Creating Faster Web Apps UI.
Other aspects have also been taken into account.
Because drag and drop is sometimes a limiting choice for developers to modify the layout, we created an in-built full-featured Code Editor that allows you to generate numerous HTML, CSS, and JS files to extend the UI of your Web Apps.
In conclusion, you may make use of the following advantages.
Drag & Drop — Pre-Made Bootstrap Blocks — Dashboard Layouts, Signup
Forms, *Login Forms, E-Commerce Order Layouts, and more
Drag and Drop — Default Bootstrap Components to improve the layout
even more, such as Buttons, Cards, and so on...
Create/Edit UI enhancements using HTML, CSS, and JS.
Use the entire project for production or future development by
downloading it.
Publish to Netlify to show off your work to potential clients.
I hope, you enjoy using this tool for creating responsive Web Apps UI faster.
This question is for web developers and architects.
How do you think is it a good or bad idea to have a website where you're able to edit all the templates (HTML, CSS, JS, images..) right from the admin panel?
In this case if you update website often, you don't need to search for a local version of your website on you development machine, search for a specific page, make modifications, commit it to source control server, make deployment.. Instead, all you need is just right click on the page or any element on this page, click Edit, update a piece of HTML and click SAVE - 30 seconds maximum - all from your browser ;)
You still can have version control system with this approach and rollback any template which was modified by mistake by 2 mouse clicks on a website.
I personally like this approach and need to know your opinion. So what do you think?
Note, we are talking about big websites which have to be updated often, multilingual ones etc.
Realworld web-applications which use this approach:
Wordpress
vBulletin
Personally, I think it would depend on the complexity of the website.
What you're talking about here is directly editing the structure (and potentially behaviour) of a live website. Sure, it may take longer to make the changes on your development server before rolling them out but if there's any chance of breaking either the appearance or functionality of the site then I'd think definitely think twice.
You shouldn't be allowed to modify the entire layout of your site through the site itself in my opinion. The reasons being the lack of version control and the inability to preview what you are doing, which translate into the inability to come back to an older version. Plus if you modify it locally, you are allowed to make errors that break everything, a luxury you can't always afford if you're doing it directly through the website.
Being able to add/remove content through the website is great though, it would be very painful to update a blog by modifying your HTML each time!
I once created a site that did exactly that. (Well, without any option for source control - had to learn that one the hard way...) Looking back at what I did there, a few things come to mind:
It was a traditional website with information about my sports club, that only changed occasionally, not a web app in the modern sense.
I wanted to be able to apply fixes even though I had no access to my dev machine (because it was a private project, I was at work, and ftp connections were not allowed by the comapny proxy).
For those specific reasons, the approach was a good solution. Today I would use one of the many good frameworks for this purpose (Joomla, Drupal etc) instead of coding it myself.
On important item: I was able to edit the pages that were used to generate the main site, but not the generation program or my admin pages. For those, I had to use my dev machine and upload file changes by ftp.
I think it is a good approach, if done correctly (my implementation certainly wasn't)
Editing HTML/CSS/JS files through your web browser can make things easier, as long as the editing implementation is neat, organized, idiot-proof, and keeps track of revisions.
A major issue to consider is security. The inability to modify actual files from the content management system in most software packages is a security precaution.
Learn to use a version control system effectively and efficiently. Tools like git or bzr can take care of a lot of the tedious stuff automatically, like package building, uploading, etc.
I hate it. Web development, much like the web servers themselves, shouldn't be "comfortable". Web development should be a mother gentle caressing scary experience. It should sound, look, even taste dangerous.
Neophyte web developers should be put through their paces learning the subtler aspects of their chosen text editor before they are even allowed to open a web browser; and not be allowed near a graphical web browser before 6 months of working only using lynx for debugging.
Laziness is our bane. No more, I say.
Edit: This is, perhaps, a bit tangential to the issue at hand. It should also be mentioned that visual identity that is too simple to change will change too often, leading to confused and frustrated users.
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 7 years ago.
Improve this question
Say I had an open-source project which I wanted to try and generate some exposure for. Would it be considered unethical to set up a project entry for it on several sites such at github, sourceforge and google code, for example?
This would be purely for giving it greater exposure. I realise there might be some practical reasons for doing this, such as wanting to use github for source control, and sourceforge for issue tracking, forums and such. For the sake if this question I'm wanting to focus more on the case where you use one of the sites as the main site for the project, and make "stub" projects on the other sites that point back to the main site.
My gut feeling is that while it may not be outrightly unethical, it might be bordering on the sleezy side...
Stick with one provider. "If you build it, they will come" :)
Besides, once people do start coming, they'll just google the project name anyway. Finding the same project on Sourceforge, Github and Google Code is just going to annoy the hell out of people.
I don't know about the ethics, but consider the practicalities:
you will have to do multiple repeated
uploads to several different sites,
doing it to a single site can be a
pain
users won't know which site to report
bugs at
if you use the SVN/CVS/git
repositories, you will have multiple
copies of your code in different
repositories - a very bad idea
I'm sure there are other problems. So stick to one site - I've been using Google Code for a small project I've just started (CSVfix, if anyone is interesed) and I can recommend Google as being very easy to set up.
I think this is fine, for the reason that each provider may have something you want. You should pick the services that are best for your project. For example:
Google code has file hosting, but the issue management is terrible, so
Launchpad has great bug tracking, but no wiki, and we use Mercurial, so
Bitbucket.org has mercurial hosting etc..
So it might be reasonable to use Launchpad for bug tracking, and Google code for hosting files and wiki, and Bitbucket.org for hosting source.
I would suggest choose your preferred host for your project. You can publish about your project on many forums. Exposure will come via search engines.
I don't know why you think it would be unethical or sleezy. Maybe you can say more about that so people could address your concerns directly. To measure that, consider if you are intentionally breaking the rules of the service, lying to anyone about how you are using the service, and being deceptive in some other way. If you are using multiple services, I don't think you have anything to hide.
Consider the Perl community, which is the one I deal with. Several projects are hosted on one of the source control services, such as SourceForge, Google Code, or Github. The main distribution for most Perl stuff is CPAN, though. Other people may distribute through Freshmeat or some other service. The main issue tracker comes from Best Practical, which hosts a free RT for every Perl module on CPAN. Most of the people I know use the best from more than one service. Indeed, the Web 2.0 way is to create applications by cobbling together services from multiple vendors. :)
You should also think about the social construction of these free sites. Places like SourceForge and Github give out free accounts, but they also sell services. They get the buzz through the free stuff that allows them to sell the premium services. I don't see anything wrong with that. If you're using the free services, just realize that in return for your free use, they get to use you as free tester, advertiser, and so on. Again, I don't see anything wrong with that. It's just part of the deal. You aren't just taking from them, you are also giving to them. There's an exchange between consenting parties.
What would be unethical, I think, is any service that forbids you to use another service or intentionally sets up a situation which would make it hard for you to use another service by not being compatible with common tools or not giving you access to your data (e.g. somehow disallowing git-svn, and so on).
Services spanning these various hosts will be inconvenient and difficult to maintain. For the above mentioned reliance on search engines to generate traffic take care to chose a name that differentiates your project from the web noise. A clear indication that traffic will not arrive is if your project first gets a re-recommendation on spelling. Take for example the people who brought you the chattr project from GNU. Immediately chatr is suggested as the proper search and your traffic will suffer accordingly.
as i has already been said having to maintain the code on several hosts will make it more trouble then it is worth. What you have to think is you would need to make sure that it uploads properly over several hosts, it would more then likely cause confusion to some over if one copy is legit and the others aren't which in turn could cause a bad name for the project before you even start.
End of the day there are much more, better ways to spread the word of your project, social networking sites, specific related forums are two main ones for you to consider, either way you would be better off spending your time posting to several sites then you would uploading and maintaining code on several sites.
I consider having several (independent) mirrors to be a benefit for the community, because such distributedness assures more reliable accessibility of your public work, now and in future (it will survive the failure of any single hosting site).
That's why I want to keep track of the available diffeent options to publicly host open-source projects:
Which public hosting sites for darcs projects are there?
Which public Git hosting sites are there that are free software?
I believe it's rather ethical (or moral) to put some effort into ensuring that your public work is published in the most accessible way (well documented, and with some guarantees about it being accessible at any moment when someone is interested).
The effort for you to push your work to several places independently (I mean, they won't depend on each other) and manage all this is probably not really a nightmare (as suggested in some other answers here), especially with a DVCS. For example, one can even set up Git so that one pushes to several places with just one command.
I feel that unless you are forcing someone to read something done by you, but you are rather just putting your stuff somewhere for it to be findable and accessible if someone is interested, you are not egoistic or ego-whatever.