This really helpful question (and answer) works great for sharing a NetLogo model through a public folder in Dropbox.
However, my understanding is that Dropbox will no longer (though for the moment still does) support sharing HTML (and so NetLogo files) this way.
The question and answer above mentioned GitHub, and in particular the URL to the "raw" HTML file, as a potential solution. I tried this but had some problems.
Here's the file hosted via Dropbox (it works) : https://dl.dropboxusercontent.com/u/1190498/Virus%20on%20a%20Network%20(Hinze).html
Here's the identical, I think, (raw) file hosted via GitHub: https://raw.githubusercontent.com/jrosen48/netlogo-models/master/Virus%20on%20a%20Network%20(Hinze).html
Thinking that the key was rendering the HTML, I tried to prepend https://htmlpreview.github.io/? to the file hosted via GitHub, to no avail.
How to share a NetLogo model through GitHub?
It's kind of sad that the rules for this keep changing, but I guess there are two things that I could kind of recommend. One is to use the NetLogo Modeling Commons. NLW versions of models uploaded there can be directly linked to, simply by uploading the .nlogo file—that is, you never even need to do "Export: HTML".
The other option—the option that I think I might recommend more strongly is to use GitHub Pages, which is essentially a free, basic web host. You can see here an example of a model that I uploaded to GitHub pages. The setup of the repository is quite trivial; I just made a repo named "[username].github.io", uploaded the exported HTML file, and then it was accessible from a predictable URL.
Related
I found a small GitHub project that I want to use (https://github.com/NewSignature/us-map) to create a clickable map. It is a jQuery plugin. I don't want to download it and clutter up my project though. Is there a way to link to the project in like a script tag and link tag?
It is possible you could use a CDN for this if the project offers one already. You could ask the project if one exists, or see if common CDNs already offer it, and use that. Otherwise, you'll need to host it yourself.
While GitHub does provide a way to view the raw contents of a file, it isn't intended as a CDN for you to use. Raw files are not hosted directly, but instead generated from the repository, so for performance and availability reasons, GitHub doesn't want people to use it as a substitute for hosting their own dependencies.
I'm publishing a tutorial that includes a lot of code interspersed with documentation. I'm considering two ways of hosting the code:
Separate git repository with code files and markdown files explaining the code
Github gist containing both of these
Are there advantages of hosting in a gist v/s a repository? When would one prefer one of these over the other?
Gist is a simple way to share snippets and pastes with others.
Whereas Repo is simply a place where the history of your work is stored.
There is no good answer, it's personal preference. I make mine a conceptual distinction. If it's code designed to demonstrate a technique, teach a principle, or show off a solution it goes in a gist. Doesn't matter if it's one file or 30 files. If it's actual code intended to be run, used as is, or forked as boilerplate I put it in a proper repository.
If you use markdown files for your tutorial, now there is one important difference, even if you are only creating one file (and specially if it is a long one).
Since April 2021, .md files created in github repositories now include an automatic Table of Contents which greatly improves navegability. See this related SO answer for more info.
As far as I know, this automatic ToC does not exist in gist-created .md files, so I'd rather go for a repository in this case (OP mentioned "a lot of code interspersed with documentation").
I have heard that, product based companies will look for what we have done outside of projects and also looking for the github profile.
In the meantime, I have created an automation application which addresses the specific requirement (Timesheet) in our organization. So, I thought of uploading this one too.
I have also done the screen cast and uploaded it to YouTube for adding in the profile (Resume).
This exact tool is not useful for all the people , but useful for the people in our organization, in which they can edit/contribute more.
Now I am having the question like, can I upload this kind of the code to GitHub?
Thanks.
Yes, you can.
Code on GitHub does not have to be useful to other people. You can push code there even if it is only useful to you or people in your organization.
You could also use a private repository if you do not want other people to see the code.
See: https://github.com/pricing
I find Jekyll to be very easy and useful to maintain static html sites and blogs, especially along with GitHub pages. Wanted to know if there are any Static site generators or CMS which helps in maintaining Jekyll sites with live preview, inline editing, layout management, file management etc.
There's an emerging market of "headless CMS" services that let you (or other writers) edit content through a web interface, and then access this content via an API. Most have webhooks that could be used to trigger regeneration of the static site when the content stored in the CMS is changed. Libraries for jekyll integrations already exist for these platforms.
List of headless CMSes:
Prismic (jekyll library)
Contentful (jekyll library)
Osmek
Storyblok (jekyll integration)
others
A few cool products fit the bill here:
CloudCannon
Siteleaf
Forestry.io
DatoCMS
Netlify CMS
jekyll-admin
Most of them sync directly with Git so devs can push directly on the repo, and non-techie users indirectly do the same by saving content (which trigger builds) in simpler UIs.
I personally like CloudCannon for its easy, more "visual" approach to editing stuff for non-technical folks (one of our dev wrote a full tuts on using CC + Jekyll for a multilingual site, should it be helpful).
Netlify CMS' open source approach is pretty neat too. The CMS is basically a react app you inject in any project.
Happy coding.
I have found these solutions:
http://www.siteleaf.com/
http://cloudcannon.com/
The second seems to be more promising to me. We basically want to develop the jekyll templates on our side, but want to have the possiblity for non-coders to edit the content online.
If you don't want to pay and you are okay with hosting a solution or do the editing offline, then you could try out this one: https://github.com/jekyll/jekyll-admin (Although I haven't tried it, but if you do, please share your experiences with me.)
I just finished with a simple editor for the same. You can find it on github here. It is still in initial release stage but it does come with live preview for editing posts on jekyll and managing them.
I'm searching for the same, as all Static site generators I found require Markdown knowledge which isn't suitable at all for my clients.
I found this great CMS (Kinda!) https://sitecake.com/
Still don't know how to manage collections with it, say listing of few products with lightbox details, but I believe it is possible.
I have a simple blog application written in Python, using Django. I use Git to version-control this website. The main content of the site is a blog. The blog entries are stored in a SQLite database (which is not version-controlled, but is backed up regularly); some entries contain images and other media (like PDFs).
I currently store this "blog media" in the repository, alongside other media (such as external JavaScript code, and images used for layout purposes -- all nicely organized, of course). It occurred to me, however, that this isn't really a good strategy, for a few reasons:
Whenever I post a new blog entry that contains an image or a link to a PDF, I have to add the image to the repo and then copy a new version to the production server -- which seems like a lot of work just to add an image. It'd be easier just to upload the image to the server (and make a local backup, of course).
Since this media is content rather than code, it doesn't seem necessary to store it alongside the code (and related style media) itself.
The repo contains a lot of binary files, which increase the overall size of the repo; and more importantly,
I never really edit these images, so why keep them under version-control?
So I'm considering removing these files from the repo, and just copying them to a directory on the server outside of the directory containing the Python code, templates, style sheets, etc., for the website.
However, I wondered: Is there a "best practice" for dealing with content images and other media in a website's repo, as opposed to images, etc., that are actually used as part of the site's layout and functionality?
Edit
To elaborate, I see a difference between keeping the code for the website in the repo, and also keeping the content of the site in the repo -- I feel that perhaps the content should be stored separately from the code that actually provides the functionality of the site (especially since the content may change more frequently, and I don't see a need to create new commits for "stuff" that isn't necessary for the functioning of the site itself).
Keep them in version control. If they never change, you don't pay a penalty for it. If they do change, well, then it turns out you needed the version control after all.
Initially, I would say don't put them in the repo because they'll never change but then consider the situation of moving your website to a different server, or hosting provider. You'd need an easy way to deploy it, and unless it's not under version control, that's a lot of copy/paste that could go wrong. At least it's all in once place if/when something happens.
This isn'y really an answer as much as it's something to consider.
Version them. Why not? I version the PSD's and everything. But if that makes you wince, I can understand. You should version the javascript and stylesheets though, that stuff is code (of sorts).
Now, if by content, you mean "the image I uploaded for a blog post" or "a pdf file I'm using in a comment", then I'd say no--dont version it. That kind of content is accounted for in the database or somewhere else. But the logo image, the sprites, and the stuff that makes up the look and feel of the site should absolutely be versioned.
I'll give you one more touchy-feely reason if you aren't convinced. Some day you'll wish you could go into your history and see what your site looked like 5 years ago. If you versioned your look & feel stuff, you'll be able to do it.
You are completely correct on two points.
You are using Version Control for your code.
You are backing up your live content database.
You have come to the correct conclusion that the "content images" are just that and have no business in your code's Version Control.
Backup your content images along with your database. You do not want to blur the lines between the two unless you want your "code" to be just your own blog site.
What if you wanted to start a completely different blog. Or your friends all wanted one.You wouldn't be giving them a copy of your database with all your content. Nor would it be any use for them to have a copy with all your content images.
Move version control systems don't work well with binary files, that being said, if they're not changing, it makes no (little) difference.
You just have to decide which is easier, backing it up on the repository and the multistep process to add an image/pdf/whatever, or maintaining a separate set of actions for them (including backup). Personally I'd keep them on the version-control. If you're not changing them it's not harming anything. Why worry about something that isn't causing harm?
I think you need to ask yourself why you are using version control and why are you making back-ups Probably because you want to safeguard yourself against loss or damage of your files and in the event of something terrible happens you can fall back on your backups.
If you use version control and a separate backup system you get into the problem of distribution because the latest version of your site lives in different places. What if something does go wrong, then how much effort is it going to take you to restore things? To me, having a distributed system with version control and backup's seems like a lot of manual work that's not easy script-able. Even more, when something does go wrong you're probably already stressed out anyway. Making the restoration process harder will probably not help you much.
The way I see it, putting your static files in version control doesn't do any harm. You have to put them some where anyway be in a version control repository or a normal file system. since your static files never change they're not taking up more space over time, so what's the problem? I recommend you just place all of it under version control and make it easy on yourself. Personally I would make a backup of my database with regular intervals and commit this backup to version control as well. This way you have everything in one place and in the case of disaster you can easily do a new checkout/export to restore your site.
I've build this website. It has over a gig of PDF files and everything is stored under version control. If the server dies, all I have to do is a clean export and re-import the database and the site it up and running again.
If you are working on a web project, I would recommend creating a virtual directory for your media. For example, we setup a virtual directory in our local working copy IIS for /images/ /assets/ etc. which points to the development/staging server that the customer has access to.
This increases the speed of the source control (especially using something clunky like Visual Source Safe), and if the customer changes something during testing, this is automatically reflected in our local working copy.