Teaching myself Go to hopefully replace my Python scripting. Being able to just load a single binary onto a server and give no fucks about environment or dependencies is addictive.
HOW I FEEL LIKE THINGS SHOULD BE, BUT JUST DOES NOT WORK
gulpfile.js unchanged, create_recipe.js also unchanged, except possibly adding that require('./editor.js') back in and accessing markdown, MediumEditor, etc. as editor.markdown, editor.MediumEditor, and so on.
editor.js
var markdown = require('markdown');
var toMarkdown = require('to-markdown');
var medium = require('medium-editor');
// gone are the window.foo assignments.
I'm pretty sure specifying modules in as 'entries' in your config means they are not accessible outside the bundle. You need to b.require() them to make them accessable outside the module. It looks like your config parameter has a 'require' field to do exactly that. If you switch to
That should let you do require(jsSourceDir + 'editor.js'). If you want to do require('editor.js') you can't do that with the code you have, you'll have to modify the b.require() call.
But why do you have editor.js at all? Why don't you bundle the modules you need (markdown, to-markdown,medium-editor) into one bundle and require() them in create_recipe.js?
I actually like PDFs. As long as they aren't forms you can't actually fill out, or 600 page, tends of megabyte monstrosities.
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
There's really nothing terribly wrong with the PDF format itself. It's not perfect, but it's competent, and it's one of those "Don't fix what's not broken because really document formats are fucking boring and do we really need to revisit these?".
LaTeX is the source language. DVI is the output of compiling TeX source (using the latex program) which can then be compiled to postscript, PDF, or printed.
Postscript is technically an alternative to PDF but there are very few reasons as to why you should use it over PDFs. PDF is pretty much it for fixed-layout documents. If you can tolerate reflowable text, then there are alternatives like epub and html that are likely easier to work with (maybe).
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
at first glance it looks like it, but where it really shines is re-usability. That and some of the background benefits (virtual dom diffs, uni data flow with flux, etc.)
The fact that literally everything you make is reusable makes it so that each time you go back to react development gets faster and faster and faster.
Making an input might seems like 'holy crap i have to write all this shit just for an input field?' but then you realize you can reuse that component forever and extend its capabilities easily because its all contained in one area, it well get more attractive.
i probably wouldn't do react for literally a one off small project that stands on its own. like a marketing website or something, makes no sense.
But for a full fledged web app or for widget building or putting together a framework, it shines.
LuvTheMonkeyHigh Sierra SerenadeRegistered Userregular
It could be suffering from the same problem Angular had - a bad tutorial (Google's own Angular tutorial is pretty bad, in my experience). I haven't seen too many other 3rd party tutorials for React that are using something other than a fork of the default either, though perhaps I should search harder.
It could be suffering from the same problem Angular had - a bad tutorial (Google's own Angular tutorial is pretty bad, in my experience). I haven't seen too many other 3rd party tutorials for React that are using something other than a fork of the default either, though perhaps I should search harder.
LuvTheMonkeyHigh Sierra SerenadeRegistered Userregular
edited May 2015
I did read that - the overall architecture makes sense (layers of components etc). I think my problem with most of the docs is they move too fast and they blow away all the reusable concepts by having you dump everything into one <script> tag in your starter html file. It's unfortunate Codecademy doesn't have anything up yet - their Angular series clicked for me almost instantly.
I did read that - the overall architecture makes sense (layers of components etc). I think my problem with most of the docs is they move too fast and they blow away all the reusable concepts by having you dump everything into one <script> tag in your starter html file. It's unfortunate Codecademy doesn't have anything up yet - their Angular series clicked for me almost instantly.
hmm yeah, honestly as soon as i found out reactjs could be done server side, i went full isomorphic with all of it. meaning you can use the same code on the server side as you do the client side.
this allows you to build components as modules and you can require() them in any view you want and all that jazz.
HOW I FEEL LIKE THINGS SHOULD BE, BUT JUST DOES NOT WORK
gulpfile.js unchanged, create_recipe.js also unchanged, except possibly adding that require('./editor.js') back in and accessing markdown, MediumEditor, etc. as editor.markdown, editor.MediumEditor, and so on.
editor.js
var markdown = require('markdown');
var toMarkdown = require('to-markdown');
var medium = require('medium-editor');
// gone are the window.foo assignments.
I'm pretty sure specifying modules in as 'entries' in your config means they are not accessible outside the bundle. You need to b.require() them to make them accessable outside the module. It looks like your config parameter has a 'require' field to do exactly that. If you switch to
That should let you do require(jsSourceDir + 'editor.js'). If you want to do require('editor.js') you can't do that with the code you have, you'll have to modify the b.require() call.
But why do you have editor.js at all? Why don't you bundle the modules you need (markdown, to-markdown,medium-editor) into one bundle and require() them in create_recipe.js?
Because medium-editor, markdown, and to-markdown will be used on 3 or 4 pages, but far from all of them. Adding all of those to page specific bundles for all of the small handful seems dumb and wasteful vs. having a single bundle with all of them which will be downloaded once and cached.
I figured out the problem, though. I needed to specify ./editor.js as an external for create-recipe.js, specify markdown and to-markdown (and medium-editor via the browserify-bower plugin) in `require`, and then, the part that I missed in all of my various different config attempts is this.
The configs and call to browserifyThis() in gulpfile.js:
var editorConfig = {
entries: [
jsSourceDir + 'editor.js',
],
cache: {},
packageCache: {},
fullPaths: true,
outputName: './editor.js',
require: ['markdown', 'to-markdown'] // I had tried this, but not without the rest of the changes. I had also tried specifying editor.js in here as you suggested.
}
var editorPlugins = [
{name: 'browserify-bower',
conf: {
require: ['medium-editor', ]
}
},
];
browserifyThis(editorConfig, editorPlugins);
var createRecipeConfig = {
entries: [
jsSourceDir + 'create_recipe.js',
],
cache: {},
packageCache: {},
fullPaths: true,
outputName: 'create_recipe.js',
//external: ['./editor.js',],
external: ['medium-editor', 'markdown', 'to-markdown'] // I had not done this
};
browserifyThis(createRecipeConfig, null);
create_recipe.js:
var MediumEditor = require('medium-editor');
var markdown = require('markdown');
var toMarkdown = require('to-markdown');
// NOT THIS
// var editor = require('./editor.js');
create_recipe.js needed to treat the actual modules I wanted as requires and specify them as external, not require the bundle which contained those modules and specify that bundle as external.
My intent is that there will be on big main.js which has the stuff used on basically every page... react, modernizr, maybe jquery (except everyone has that cached from elsewhere, so maybe not), etc. A few bundles like editor.js where they are used in several places, so duplicating them in the page specific bundles is wasteful, but not used in enough places and in places which many users may never see, so it may make sense to keep them separate, and then the page specific bundles as necessary. The feature specific bundles, like editor.js, may turn out to be pointless, but I'm experimenting, and the general idea was going to need to be figured out for main.js + page sepcific bundles anyway.
I'm putting together a little learning group for beginner web devs and rails. I'd like to put together a portable Linux dev environment for them, since they are largely Windows users with moderate power user knowledge.
Does anyone have any recommendations? I'm thinking some combination of Vagrant, Git and Atom, but I'm not sure whether I should have them develop in Windows in the Vagrant folder or do things actually in Linux, which would require them to learn something else on top of web dev. Any other configurations or suggestions are welcome!
I text-edit and such in Windows in the Vagrant folder and use the Vagrant box to run command-line tools. Seems natural, and it's often easier to get web-dev utilities configured right in Linux.
That seems like how you're supposed to use Vagrant. What do you do in Windows to get it set up?
So far I've got:
Install VirtualBox
Install Vagrant
Install Git
Install ConEmu and point it at Git Bash
Which seems to do okay. I feel like this is the most that I want to lay on people who just want to start coding, but it will probably be okay if they're dedicated enough.
I dual OS installed Ubuntu on my home desktop, and now whenever it boots up I just choose the Windows 7 loader. If I want to mess around with Rails, I boot into Linux and have fun. You could do something similar for them. Ubuntu isn't that hard to use.
It's not about Ubuntu being easy/hard. It's about people who are not typical compsci people trying to figure out the whole webs thing. Your solution sounds like a great way to work things for people like us who enjoy both artisinally crafted terminal emulators and playing games on Steam.
For beginners? I feel like I would lose them at "dual OS install."
Well if it's beginner I'd say just stick with Windows at first and if they like the group enough then you can slowly migrate them to Linux. I'm doing web development in Windows and it's not that bad. I'm not actually sure why people give me shit about it all the time actually.
I honestly think that Windows hasn't deserved the level of shit it gets since ME. I really like a lot about 7, 8(.1) and even Vista. Not to mention that Visual Studio has been both best in class and available as a free download for over a decade. It's a solid dev platform.
In this case, it's largely that I want to create a clean, reproducible dev environment for them. Which means stuff like Vagrant / Docker has to get involved. At that point, I might as well set up a VM for them with an OS that is common for rails.
Is there a reason you can't just say "go get node, go get npm, go get bower, use your text editor of choice" on windows / OSX / linux, and use railsinstaller for that? When it comes to deploy time, sure, the environment will be more important, but for just basic web stuff it seems like all you really need to make is some text files so you could start with notepad/vi/textedit -- there's railsinstaller for that stuff (though I don't know much about rails myself -- is it really picky about the exact way it's set up / has a bunch of other dependencies / that sort of thing?)
Well if it's beginner I'd say just stick with Windows at first and if they like the group enough then you can slowly migrate them to Linux. I'm doing web development in Windows and it's not that bad. I'm not actually sure why people give me shit about it all the time actually.
I honestly think that Windows hasn't deserved the level of shit it gets since ME. I really like a lot about 7, 8(.1) and even Vista. Not to mention that Visual Studio has been both best in class and available as a free download for over a decade. It's a solid dev platform.
In this case, it's largely that I want to create a clean, reproducible dev environment for them. Which means stuff like Vagrant / Docker has to get involved. At that point, I might as well set up a VM for them with an OS that is common for rails.
Windows does get a lot of shit. For stuff like using UTF-16... since they put unicode in long before UTF-8 was even a thing. And having complex APIs... because they had features in decades before linux did and can't withdraw APIs... and because they still have the 16-bit APIs in... and because the COM documentation is crap, which it is, but try to look up comparable docs for a systemwide RPC system elsewhere. The best criticism is that command line shells are pretty poor, and NTFS is relatively slow
Posts
Tried the PDF again as SHA-1 instead of SHA-256, still different but match what you see.
It is something with the file, I suspect it is terminating early somehow which might be due to how they upload the files?
Yeah that might be it too.
I'm going to turn on hashing for text/jpg files just to pass the test because fuckkkkkkk that noise.
Looks like md5online automagically appends a newline to the end or something.
Pure binary read produces the same results no matter what. I suspect it's because PDFs aren't necessarily binary.
That one your proctor is using is busted, point to the other sites to show him that.
I was about to lose my mind.
The dev server I was using for certification went down and I struggled to get that working.
That screwed up how much time I had to troubleshoot some stuff.
Then this shit.
Ugh.
Now I gotta figure out why mcrypt in PHP does shit differently than sha encryption in C#
Well that has plenty more factors, you're trying to encrypt in one and decrypt in the other?
Yup, two way too.
I'm going to see if I can circumvent that just by using SSL instead.
I'm pretty sure specifying modules in as 'entries' in your config means they are not accessible outside the bundle. You need to b.require() them to make them accessable outside the module. It looks like your config parameter has a 'require' field to do exactly that. If you switch to
var editorConfig = { require: jsSourceDir + 'editor.js', cache: {}, packageCache: {}, fullPaths: true, outputName: './editor.js', }That should let you do require(jsSourceDir + 'editor.js'). If you want to do require('editor.js') you can't do that with the code you have, you'll have to modify the b.require() call.
But why do you have editor.js at all? Why don't you bundle the modules you need (markdown, to-markdown,medium-editor) into one bundle and require() them in create_recipe.js?
I'm actually surprised someone hasn't made a competing format yet.
… that's about as far as it went, too.
Nintendo Network ID: AzraelRose
DropBox invite link - get 500MB extra free.
Huh. Never heard of that.
Wonder what it's got going for it.
Nintendo ID: Incindium
PSN: IncindiumX
LaTeX is the source language. DVI is the output of compiling TeX source (using the latex program) which can then be compiled to postscript, PDF, or printed.
Postscript is technically an alternative to PDF but there are very few reasons as to why you should use it over PDFs. PDF is pretty much it for fixed-layout documents. If you can tolerate reflowable text, then there are alternatives like epub and html that are likely easier to work with (maybe).
Ticket Closed: WorksForMe
I upped my timeout setting to 60 seconds and it works now. Weird.
Nintendo ID: Incindium
PSN: IncindiumX
The fact that literally everything you make is reusable makes it so that each time you go back to react development gets faster and faster and faster.
Making an input might seems like 'holy crap i have to write all this shit just for an input field?' but then you realize you can reuse that component forever and extend its capabilities easily because its all contained in one area, it well get more attractive.
i probably wouldn't do react for literally a one off small project that stands on its own. like a marketing website or something, makes no sense.
But for a full fledged web app or for widget building or putting together a framework, it shines.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
also unfortunately none of the code school places (codecademy, codeschool.com, etc.) have a react tutorial/guide up yet.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
this post really helped me in the beginning:
https://facebook.github.io/react/blog/2013/11/05/thinking-in-react.html
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
am I the only one looking at that picture and going "code waifu
hmm yeah, honestly as soon as i found out reactjs could be done server side, i went full isomorphic with all of it. meaning you can use the same code on the server side as you do the client side.
this allows you to build components as modules and you can require() them in any view you want and all that jazz.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
I figured out the problem, though. I needed to specify ./editor.js as an external for create-recipe.js, specify markdown and to-markdown (and medium-editor via the browserify-bower plugin) in `require`, and then, the part that I missed in all of my various different config attempts is this.
The configs and call to browserifyThis() in gulpfile.js:
var editorConfig = { entries: [ jsSourceDir + 'editor.js', ], cache: {}, packageCache: {}, fullPaths: true, outputName: './editor.js', require: ['markdown', 'to-markdown'] // I had tried this, but not without the rest of the changes. I had also tried specifying editor.js in here as you suggested. } var editorPlugins = [ {name: 'browserify-bower', conf: { require: ['medium-editor', ] } }, ]; browserifyThis(editorConfig, editorPlugins); var createRecipeConfig = { entries: [ jsSourceDir + 'create_recipe.js', ], cache: {}, packageCache: {}, fullPaths: true, outputName: 'create_recipe.js', //external: ['./editor.js',], external: ['medium-editor', 'markdown', 'to-markdown'] // I had not done this }; browserifyThis(createRecipeConfig, null);create_recipe.js:var MediumEditor = require('medium-editor'); var markdown = require('markdown'); var toMarkdown = require('to-markdown'); // NOT THIS // var editor = require('./editor.js');create_recipe.js needed to treat the actual modules I wanted as requires and specify them as external, not require the bundle which contained those modules and specify that bundle as external.
My intent is that there will be on big main.js which has the stuff used on basically every page... react, modernizr, maybe jquery (except everyone has that cached from elsewhere, so maybe not), etc. A few bundles like editor.js where they are used in several places, so duplicating them in the page specific bundles is wasteful, but not used in enough places and in places which many users may never see, so it may make sense to keep them separate, and then the page specific bundles as necessary. The feature specific bundles, like editor.js, may turn out to be pointless, but I'm experimenting, and the general idea was going to need to be figured out for main.js + page sepcific bundles anyway.
That seems like how you're supposed to use Vagrant. What do you do in Windows to get it set up?
So far I've got:
Which seems to do okay. I feel like this is the most that I want to lay on people who just want to start coding, but it will probably be okay if they're dedicated enough.
It's not about Ubuntu being easy/hard. It's about people who are not typical compsci people trying to figure out the whole webs thing. Your solution sounds like a great way to work things for people like us who enjoy both artisinally crafted terminal emulators and playing games on Steam.
For beginners? I feel like I would lose them at "dual OS install."
I honestly think that Windows hasn't deserved the level of shit it gets since ME. I really like a lot about 7, 8(.1) and even Vista. Not to mention that Visual Studio has been both best in class and available as a free download for over a decade. It's a solid dev platform.
In this case, it's largely that I want to create a clean, reproducible dev environment for them. Which means stuff like Vagrant / Docker has to get involved. At that point, I might as well set up a VM for them with an OS that is common for rails.
Windows does get a lot of shit. For stuff like using UTF-16... since they put unicode in long before UTF-8 was even a thing. And having complex APIs... because they had features in decades before linux did and can't withdraw APIs... and because they still have the 16-bit APIs in... and because the COM documentation is crap, which it is, but try to look up comparable docs for a systemwide RPC system elsewhere. The best criticism is that command line shells are pretty poor, and NTFS is relatively slow