I personally would say that a boilerplate is like a single snippet that can be pasted. But there are repos like this one: https://github.com/h5bp/html5-boilerplate
So, what should be the difference? Google search doesn't really provide an useful answer. Since the actual dictionary definitions of these terms are completely different from their meaning in programing.
Boilerplate: repetitive stuff that is necesssary, yet you get to type it out again and again and again, and it just feels like it wastes time to have to do it so many times. Most frameworks try to reduce boilerplate as much as possible while still being flexible enough to cover all necessities.
Scaffolding: a starting point for your program (or part of it), generated by some tool. You take it and tweak it to your needs. This combats the boilerplate problem by automatically generating some of it so you don't need to type it by hand.
Boilerplate: static template or templates likes 'sample code'. Files for re-useing in project by copy-paste, and then modify it as the need.
Scaffolding: templates with some placehold (variable), used by some tool(like project widzard) to generate the start point of project. For example the npm init.
Related
Max, I want to update my extension to the new format, but I am running into issues with placement of custom code. It seems that the extension framework has been updated a lot since I added an extension 4 years ago. Is there a way to get better documentation on getting started with adding a extension? I am happy to help write up the documentation if you can help answer some questions that I think would help get people started. Let me know.
The only thing that really changed is that the scaffolder creates a webpack project for you. The extension registering procedure is the same: http://js.cytoscape.org/#extensions/api
For example, cytoscape( 'collection', 'fooBar', function(){ return 'baz'; } ) registers eles.fooBar().
I guess the main thing is that there are a lot more files than what the previous scaffolder generated, so it might be harder to find things. The layout output has lots of files, because it creates a skeleton impl for each of the continuous case and the discrete case.
The scaffolder isn't strictly necessary. You could use another build system (or none at all) as long as you call cytoscape(). For example, if you only care about publishing to npm for people who use webpack/browserify/rollup, then you could just use cjs require('cytoscape') to pull in the peer dependency. Exporting a register function is nice if you want to allow the client to decide the order of extension registrations with cytoscape.use(extension) (or extension(cytoscape)).
You're right that there should be some more docs on the output of the scaffolder. Maybe a summary of the files would suffice. We could add a tutorial in the blog later if need be. Both the docs and the blog just use markdown, so the content could go in either place.
Where do you store your old classes and files, which you don't longer use in a current project?
I have quite a few classes and files, which are no longer required, but which I would like to keep somewhere in case I need to reuse some of the code later.
Currently, I am just copying and pasting the code in a tool called Code Collector Pro.
However, since this seems not to be the most elegant way of storing old code, I would like to ask you: How do you save your old code?
If you are talking about handy snippets of code that you might use often I store them in Xcode's Code Snippet Library (just drag selected code in to create a snippet.)
Generally though, I delete unused code. If I need it again it will be in my version control system.
I would definitely use a version control system (I'm most familiar with Subversion, but am getting into Git now). If this is code that's worth keeping around then it's code you'll likely use and modify in multiple projects over time. You'll want to be able to review the history of your changes, compare how you used it differently in project A vs. project B, and maintain notes to help refresh your memory and to help in keyword searching when you're trying to find that bit of code you remember using two years ago.
You can set up repositories however makes sense for your work - by project, by code type, etc.
I'm not familiar with Code Collector Pro - if it works as a GUI for a version control system, it may be fine for what you're doing.
I'd like to be able to Alt-Click an instance variable (or a method) as part of the program i created and read what it's purpose is.
The fact that Xcode is telling me the class variable is declared at - is nice but not enough. In this case i'd like to see custom text i typed to describe what an asset really is. Additionally type of the ivar would also be useful to know.
How can this be done? In this case, i wonder what exactly did i mean by assets
I specifically wonder if this information can be viewed from inside Xcode, similar to how Eclipse shows JavaDoc content.
You would need to create a documentation set for your project and install it in Xcode. appledoc can help you with this. This is a command-line tool that can generate documentation in Apple's style from specially formatted comments in your headers. You can also integrate this into your build process with a run script build phase, so that documentation is always up-to-date.
For small projects, it's usually not worth the effort though and you're probably better off just adding comments to your header files and jumping there with Cmd-click (Ctrl+Cmd+left-arrow to go back to where you came from).
You'll probably want to take a look at Apple's documentation on Documentation Sets as well as their article on generating doc sets using Doxygen. The latter is based on Xcode 3.x, so how relevant it is is somewhat questionable, but it'd be a good idea to take a look nonetheless.
That said, if you decide to use Doxygen (alternatives like HeaderDoc can be used for documentation, but I'm not sure what's available to you as far as creating doc sets goes), it looks like the main point is you'll want to throw GENERATE_DOCSET=YES into your Doxyfile (or whatever you decide to call it). After that, you'd just throw the results into ~/Library/Developer/Shared/Documentation/DocSets (according to Doxygen's documentation). I don't know whether this works in Xcode 4.x - it's worth a shot though, and it'd be nice to hear back on it.
Note: most of this was based on this answer by Barry Wark. Figure credit is due there, since I wouldn't have bothered looking into this were it not for his answer.
In my Cocoa development, every so often I include a header into a source file so I can use a particular class in it. But then later I delete that code from the source file, and forget (or don't really want to worry about) deleting the corresponding #import.
With time, a lot of redundant #import lines pile up in my source files, throughout the codebase.
Now, I know that these lines cause no harm, but is there any easy way to get rid of them automatically? At least it would make the top of every file cleaner ;)
There's a tool that does this for C and C++, but as far as I could tell, it doesn't yet support Objective-C. I've filed a ticket to ask for that.
nothing comprehensive off the shelf comes to mind.
1) JetBrains' AppCode may help. It's quite young at this time (e.g. not even 'beta', but it is publicly distributed), and doesn't fully understand structures of includes and nontrivial xcode projects and build settings, but it is likely smart enough to handle simpler cases.
2) you could create some scripts to accomplish what you're after. it wouldn't be terrible if you already have a project which builds out everything using common build settings. doing this manually is a pain, and is usually not a good use of time in larger projects if you are not using a high level of automation.
I found the Wikipedia entry on the soft coding anti-pattern terse and confusing. So what is soft coding? In what settings is it a bad practice (anti-pattern)? Also, when could it be considered beneficial, and if so, how should it be implemented?
Short answer: Going to extremes to avoid Hard Coding and ending up with some monster convoluted abstraction layer to maintain that is worse than if the hard coded values had been there from the start. i.e. over engineering.
Like:
SpecialFileClass file = new SpecialFileClass( 200 ); // hard coded
SpecialFileClass file = new SpecialFileClass( DBConfig.Start().GetConnection().LookupValue("MaxBufferSizeOfSpecialFile").GetValue());
The main point of the Daily WTF article on soft coding is that because of premature optimization and fear a system that is very well defined and there is no duplicated knowledge is altered and becomes more complex without any need.
The main thing that you should keep in mind is if your changes actually improve your system and avoid to lightly label something as anti-pattern and avoid it by all means. Configuring your system and avoiding hardcoding is a simple cure for duplicated knowledge in your system (see point 11 : "DRY Don't Repeat Yourself" in The Pragmatic Programmer Quick Reference Guide) This is the driving need behind the suggestion of avoiding hardcoding. I.e. there should be ideally only one place in you system (that would be code or configuration) that should be altered if you have to change something as simple as an error message.
Ola, a good example of a real project that has the concept of softcoding built in to it is the Django project. Their settings.py file abstracts certain data settings so that you can make the changes there instead of embedding them within your code. You can also add values to that file if necessary and use them where necessary.
http://docs.djangoproject.com/en/dev/topics/settings/
Example:
This could be a snippet from the settings.py file:
num_rows = 20
Then within one of your files you could access that value:
from django.conf import settings
...
for x in xrange(settings.num_rows):
...
Soft-coding: it is process of inserting values from external source into computer program. like insert values through keyboard, command line interface. Soft-coding considered as good programming practice because developers can easily modify programs.
Hard-coding. Assign values to program during writing source code and make executable file of program.Now, it is very difficult process to change or modify the program source code values. like in block-chain technology, genesis block is hard-code that cannot changed or modified.
The ultimate in softcoding:
const float pi = 3.1415; // Don't want to hardcode this everywhere in case we ever need to ship to Indiana.