Using these instructions I was able to easily install node.js on RPi. The problem was that since build v0.10.29 node.js has not included a build for the RPi. The current build is v0.10.31.
Does anyone know why node.js stopped including the RPi build with their new versions?
Is there a way to get the latest RPi build from another source?
This is my first question on SO, so hopefully I haven't mucked it up too much.
I took a look at the google group Zlatko suggested. I found that Nathan Rajlich compiles the RPi builds, but has run into an issue since v0.10.29.
Currently, however, v0.10.29 and v0.10.30 are failing to compile on ARM out-of-the-box. Follow this issue for updates on that: https://github.com/joyent/node/issues/8062.
It seems there is some hacking around to deal with the errors cropping up. It is beyond me, which is why I liked the node.js build for the RPi in the first place. I will continue with the old node.js build and hope for a RPi build in the future.
Follow these instructions here:https://github.com/audstanley/Node-MongoDb-Pi
You'll get nodejs v5.3.0 and MongoDb on the pi view the read me on how to install. Only four lines of code you'll need to copy paste into your CLi, and you'll have nodejs and MongoDb up in about five hours. (Mongodb takes quite some time to compile).
Related
I have migrated my meteor 1.2.1 code base to meteor 1.3.0 and also moved all client code to imports/ui to utilize lazy loading feature for imports folder.
My problem is, If I am changing any client side file its restarting every time, which slows down development time in meteor 1.3.0 as I have to wait for building process.
Please provide your suggestion or best approach to overcome this issue.
As I have used Meteor 1.3.0 imports directory structure I have faced that issue but below are solution.
I am posting answer to my question as I have found reason why Meteor rebuilding my client side code, When I change any file.
Currently I am using /imports/ui/ for storing client side code. As you all know ui directory doesn't have any special purpose in Meteor build.
So, it assume this code as client or server code and rebuild and restart meteor app every time.
If you rename that folder/directory to client then it only refresh client side code not full app because client folder have special meaning in meteor.
Moreover now you can also use latest version of meteor which help to speed up startup building your app.
Hope this will help you solve problem.
Meteor 1.4.2 is been released in these days.
In the official forum they say: The big news is improved rebuild performance.
Maybe you should give a try.
We are currently building our frontend js codebase (angularjs) using nodejs with grunt, which seems to be a popular setup, but we are not happy with this solution. Does anyone have suggestions for a build setup for e.g. linting, minimizing our js, running less, etc (in addition to some custom steps for angular in general and for our application specifically) without using nodejs at all?
I would leave it at that to avoid starting a flamewar, but here are, for context, some of the shortcomings of the current setup in our view:
grunt does not have even the basic functionality of a 1970s build system, like automatically re-building only files that have been modified based on file modification time
npm is causing constant headaches running on our build servers at every build
If grunt does not have even the basic functionality of a 1970s build system, why won't you use a 1970s build system then?
Just use make if that's what you're happy with. It still works fine. There's no reason not to use it if it you're satisfied with how it works.
I’ve just created my first Node.js application in Netbeans. I mean, this is a brand new project. I haven't done anything and I’m already getting an error. Maybe there is a step to configure this or a file to create or something to install but I've googled for information to no avail. I guess this is just too basic, because I couldn’t find anything out there to help.
What does this mean and how can I fix it?
Duh! I found it. For some reason the Node path and the npm path were defaulting to Program Files (x86) and nodejs was installed in Program Files. I feel dumb.
Plus, as soon as I fixed it, all other new projects were fixed.
My question is more on the lines of strategy than actual implementation.
And basically I'm wondering why do we build our MEAN apps on the server? And by build I mean getting components (npm install && bower install) and doing all the concat and minify stuff.
I'm trying to create my build system, and up until now I've been using a version of John Papa's build system, but my build is taking longer and longer on the server. So doesn't it make sense to just build everything locally and deploy it to the server? Or am I missing something?
Thanks
The build shouldn't happen on runtime. You have it partially right, build upfront, than deploy created artifact.
But the crucial idea is to have Continuous Integration in place. Meaning build server that is not on your local machine, which takes the code from SCM, builds it, run the tests, create deployable artifact and store it in some artifact repository (e.g. npm registry).
If you take it further and you also automatically deploy artifact into non-PROD envs, you are starting to dig into Continuous Delivery space.
If this build and deploy pipeline installs the artifact into PROD every commit, you are having Continuous Deployment working.
EDIT - reaction on comment:
The main idea is to have it continuous. Meaning, the full build is kicked off on regular basis, optimally every commit/git push.
If this is configured on you local machine and you are one man shop, that is probably fine. But as I played in my free time with various projects, I found that build on every commit may be resource intensive for my local machine and it was convenient to leave this responsibility for some third party service (especially when it's free).
There are plenty of online solutions for CI servers.
I used with success http://codeship.com and http://drone.io. http://cloudbees.com gives you hosted Jenkins. For open source projects they are free.
If you projects are not open source you will need to spend some bucks on it, but it should be cheap for one man projects.
I am trying to learn Electron (Atom-Shell) but I am finding it pretty tough to find documentation for it...
I am simply trying to figure out how to create a link with in index.html, and have it open a terminal window or run some sort of program.
I learn languages by learning specific tasks as I need them in a program, so that is why I am asking so then I can utilize the technique used in other ways in my programs.
Thank you for helping.
Well, essentially Electron is just a customised version of a Chromium browser that comes packaged with Nodejs and some really cool packages that basically allow you to run the custom browser as if it was a native platform application. Because of that creating an Electron app is very similar to creating a web-app that has a Nodejs back-end.
So to get started with a simple "Hello World!" app, you can just run the following npm...
npm install electron-prebuilt --save-dev
Once the npm is installed you'll need three files to run an Electron app.
A package.json file
A javascript file (default is main.js)
An html file (default is index.html)
See this GitHub repo for a quick copy/paste version of each and more detailed instructions: https://github.com/mafintosh/electron-prebuilt
after that you're ready to simply run your app...
$ electron .
Finally, one way to open a terminal window would be to use an onclick attribute in your html to trigger a child_process, found here, in a function.
That's it! You should be able to edit your html and javascript files as you would for any web-app, and take advantage of the added features that Electron provides.
I'd also check out these resources for more info:
A Quick Start intro to how Electron works -- https://github.com/atom/electron/blob/master/docs/tutorial/quick-start.md
The Atom discussion forum (Because Atom was built with Electron, and is made to be hackable, the community is quite active) -- https://discuss.atom.io/c/electron
A cool repo to keep up with the latest info. It includes links for apps that currently use Electron, tutorials, videos, and more --
https://github.com/sindresorhus/awesome-electron
I hope that helps!