|
Redmark posted:The hardest part has actually been using the native terminal, which is absolute garbage. My man have I got some good news for you https://conemu.github.io/
|
#
?
Nov 4, 2016 18:53
|
|
|
|
| # ? May 22, 2024 08:30 |
|
|
Does that work with the Linux subsystem? I admit that I don't really know much about the internals but as far as I can tell normal Windows processes can't access the other side's filesystem, though you can the other way around.
|
|
#
?
Nov 4, 2016 19:09
|
|
|
Redmark posted:Does that work with the Linux subsystem? I admit that I don't really know much about the internals but as far as I can tell normal Windows processes can't access the other side's filesystem, though you can the other way around. ConEmu isn't a shell, it's a better GUI to the shell of your choice. It should work with anything.
|
|
#
?
Nov 4, 2016 19:30
|
|
|
I see. I think the issues are with the shell itself, in that case, not with the interface. Certain key combinations don't work, and certain things don't (re)display correctly. Checking Github though it seems like they're fixing it in future builds, so I'll just have wait for the next Windows release.
|
|
#
?
Nov 4, 2016 19:59
|
|
|
Redmark posted:The hardest part has actually been using the native terminal, which is absolute garbage. The second hardest part is the Webpack documentation, which is merely trash. I've learned that documentation will always be trash because by the time someone writes out documentation, it's out of date.
|
|
#
?
Nov 4, 2016 21:41
|
|
|
The Merkinman posted:I've learned that documentation will always be trash because by the time someone writes out documentation, it's out of date. This is just not true in some ecosystems. Don't take it for granted because some libraries actually give a poo poo about documenting well and it's a well considered part of the project... unfortunately that's rare in JavaScript land, even, somehow, if you're a project that's nearly used by the whole intended user base...
|
|
#
?
Nov 4, 2016 23:49
|
|
|
I've found the Webpack documentation quite good actually. It's a bit disorganized yes, but extremely helpful when you find the right page. It's like the developer who wrote it went all out on it to help you. wide stance fucked around with this message at 03:55 on Nov 5, 2016 |
|
#
?
Nov 5, 2016 03:50
|
|
|
That's probably the first time I've ever heard anyone call the webpack documentation "quite good". Anyway, I came across this article about getting started with Webpack 2, and I bet it will help people understand webpack in general not just webpack 2.
|
|
#
?
Nov 6, 2016 16:49
|
|
|
What is the easiest/lightest way to implement routing. I'm not looking to really use any features out of a framework besides the routing and possibly modals and form validation. Please recommend something for me. ModeSix fucked around with this message at 21:52 on Nov 6, 2016 |
|
#
?
Nov 6, 2016 21:49
|
|
|
Can someone familiar with Jekyll / github pages help me out? My understanding is that gh-pages will render and serve a site built from the source files in the repository, so it's not necessary to build your site locally before pushing to github. What I can't find anywhere is a bare-bones source directory structure for a hello-world style jekyll project with a front page and some blog entries. I want something with markdown source files, whose built html I can observe from the published page (ie, Newf.github.io) and tweak accordingly. Instead of finding such a thing, I'm finding YO generators that take >10 minutes to run and produce directory structures with 100s (1000s?) of files. I thought that I'd get close to what I wanted from github's automatic pages generator, but it takes your markdown input, theme selection, etc and places built html/css in your repo, rather than the jekyll source material. Where do I look for a smallest possible ghpages friendly jekyll project?
|
|
#
?
Nov 6, 2016 22:05
|
|
|
There are a whole bunch of examples here along with links to the repos with the jekyll "source". Your initial understanding is correct, github will build from the jekyll source when you push to the repo. The first one in the list is probably one of the simplest. An index.html, _posts and _layout.
|
|
#
?
Nov 6, 2016 23:33
|
|
|
Thermopyle posted:That's probably the first time I've ever heard anyone call the webpack documentation "quite good". One caveat is I started with Webpack 2 :/ But seriously it's very helpful with examples with explanations and is frequently updated. It reads like a coworker guru wrote on the department wiki it trying to get everyone to their level while making them look studious, hard to explain but I've never encountered documentation so helpful.
|
|
#
?
Nov 7, 2016 01:44
|
|
|
Xik posted:There are a whole bunch of examples here along with links to the repos with the jekyll "source". Your initial understanding is correct, github will build from the jekyll source when you push to the repo. Thanks much. I had found that list, but clicking randomly through the projects led to information overload and the same fatigue that gets me every time I poke my head into web programming in general. It's strange to me that GH doesn't have a bulldozed path to getting a jekyll published site up. Instead they repeatedly link to to jekyll / jekyll docs, which are all about installing the tool-chain to build locally.
|
|
#
?
Nov 7, 2016 03:15
|
|
|
wide stance posted:One caveat is I started with Webpack 2 :/ One of the big goals with webpack 2 is improving the documentation.
|
|
#
?
Nov 7, 2016 03:37
|
|
|
Typescript has some really weird issues with plain old javascript. Today I had trouble with Object.keys. Typescript doesn't seem to like accessing object properties using the someObject[key] syntax, you have to use a weird workaround. Also is there any easy way of copying a super interface's properties to a sub interface object? I had one interface that just added one field to the super interface and wanted to copy the relevent properties over when I construct the sub interface object. And yarn doesn't really seem to work for me either. 
|
|
#
?
Nov 7, 2016 20:52
|
|
|
Wheany posted:Also is there any easy way of copying a super interface's properties to a sub interface object? It doesn't just inherit them?
|
|
#
?
Nov 7, 2016 21:34
|
|
|
Wheany posted:Typescript has some really weird issues with plain old javascript. Today I had trouble with Object.keys. Typescript doesn't seem to like accessing object properties using the someObject[key] syntax, you have to use a weird workaround. I don't understand this at all, I do this all the time in TypeScript. Perhaps you mean, you have given an object a type, with explicit X and Y fields. Then you try to access it like an associative array? In this case, I think this is by design. If you want an object to behave like a hashtable, give it a type of one. [code] var hashtable: { [ key:string] : IMyObject } = {}; [code] You can also simply treat your objects as <any> all the time, and it won't complain, but you are basically negating the point of using TypeScript. Wheany posted:Also is there any easy way of copying a super interface's properties to a sub interface object? You can just extend interfaces to 'add' a field. However, this doesn't magically provide a deep copy mechanism, you'll have to either do that yourself or use something like the one provided by lodash. Keep in mind, TypeScript isn't 'real', it's not running in the browser, JavaScript is. TypeScript is just a really smart linter.
|
|
#
?
Nov 7, 2016 23:21
|
|
|
Skandranon posted:You can also simply treat your objects as <any> all the time, and it won't complain, but you are basically negating the point of using TypeScript. Exactly
|
|
#
?
Nov 8, 2016 09:59
|
|
|
On the subject of TypeScript, how are you supposed to handle creating types representing data retrieved from an API? When I was working with Angular2 I often used <any> to indicate JSON data returned by the server. It felt futile to create a representation of that data because it could potentially change in the future (add a new field, etc...).
|
|
#
?
Nov 8, 2016 15:41
|
|
|
IAmKale posted:On the subject of TypeScript, how are you supposed to handle creating types representing data retrieved from an API? When I was working with Angular2 I often used <any> to indicate JSON data returned by the server. It felt futile to create a representation of that data because it could potentially change in the future (add a new field, etc...). I won't matter to the compiled code whether the response structure changes unless it breaks the handler code, which would happen either way if it changes in the wrong/right way. e: 'response structure' is more clear, I think Munkeymon fucked around with this message at 16:55 on Nov 8, 2016 |
|
#
?
Nov 8, 2016 16:53
|
|
|
IAmKale posted:On the subject of TypeScript, how are you supposed to handle creating types representing data retrieved from an API? When I was working with Angular2 I often used <any> to indicate JSON data returned by the server. It felt futile to create a representation of that data because it could potentially change in the future (add a new field, etc...). This, there's also plenty of libraries to do it on the fly for Java etc if you google around.
|
|
#
?
Nov 8, 2016 16:56
|
|
|
Wheany posted:Exactly You are missing the point of using TypeScript. Stop accessing objects as if they are all associative arrays. Either type them as hashtables, or give them fixed interfaces. Otherwise, TypeScript can't fulfill it's primary purpose (type safety, type inference). TypeScript doesn't have weird issues with plain old JavaScript, you have weird issues with TypeScript.
|
|
#
?
Nov 8, 2016 17:34
|
|
|
I just dove face-first into this stuff for the first time in my life. The dynamics of it were not lost on me. I have no drat clue what to make of the whole mishmash, but I fortunately have some tribal knowledge in my team around Django and Angular. I started with looking that up and wound up running into tutorials that threw in WebPack. I blew the afternoon fighting with it, but I think I got it to work. Can somebody explain the significance of WebPack?
|
|
#
?
Nov 12, 2016 10:13
|
|
|
Here's what I use it for:
It has other nice features that I don't really care about. Honestly Webpack isn't worth the trouble unless you have a fairly complicated app and/or are using React or another framework that involves writing lots of JavaScript modules.
|
|
#
?
Nov 12, 2016 10:35
|
|
|
Rocko Bonaparte posted:I just dove face-first into this stuff for the first time in my life. The dynamics of it were not lost on me. I have no drat clue what to make of the whole mishmash, but I fortunately have some tribal knowledge in my team around Django and Angular. I started with looking that up and wound up running into tutorials that threw in WebPack. I blew the afternoon fighting with it, but I think I got it to work. Can somebody explain the significance of WebPack? WebPack is a more advanced Browserify, in that it allows you to bundle together and use CommonJS modules into a single file. It also allows bundling HTML/CSS into that same .js file. It can help a lot for large applications, but is probably overkill for smaller ones. It is also not helpful if you aren't using CommonJS modules, which Angular 1.x does not, so making it work in situations it wasn't built for can become more trouble than it's worth.
|
|
#
?
Nov 12, 2016 19:31
|
|
|
Skandranon posted:WebPack is a more advanced Browserify, in that it allows you to bundle together and use CommonJS modules into a single file. It also allows bundling HTML/CSS into that same .js file. It can help a lot for large applications, but is probably overkill for smaller ones. It is also not helpful if you aren't using CommonJS modules, which Angular 1.x does not, so making it work in situations it wasn't built for can become more trouble than it's worth. Just to make this clear, it's also very common to use Babel with webpack and thus never seen CommonJS modules because you're using ES6 modules.
|
|
#
?
Nov 12, 2016 19:40
|
|
|
Haha I'm hosed. I don't even know what any of those technologies are that all three of you posted. Okay--I am trying to use Angular, sure. There's one. And I get partial credit for JS, HTML, and CSS. But the others? Ugh. If I understand all this, I can't even really find a writeout of everything because it's changing so fast.
|
|
#
?
Nov 12, 2016 20:19
|
|
|
Rocko Bonaparte posted:Haha I'm hosed. I don't even know what any of those technologies are that all three of you posted. Okay--I am trying to use Angular, sure. There's one. And I get partial credit for JS, HTML, and CSS. But the others? Ugh.  all of these things have been in use for years.ES6: ECMAScript 6, a recent version of Javascript that brings nice things like lambda functions and destructuring and a whole laundry list of other stuff. Javascript is also updating at a pace of about one new release a year and now has a naming scheme with the year it's released so you'll also see things like ES2016 and ES2017 going forward. Browsers can't possibly support future versions of Javascript at all times since someone on the browser team has to support the new features so while they're busy updating the browsers to use new Javascript features you'll have to use: Babel.js: JS is an interpreted language and browsers only support a certain version at a time. Babel is a utility for taking code written in certain versions and transpiling them to be able to run in another version. The most common was ECMAScript version 6 to compile to ECMAScript version 5, but now (new/current) browsers mostly support ES6. There's like no competition in this space, and you should always use Babel. CommonJS: is a way of importing and exporting modules in JS. It is one of three -- AMD (garbage, jettison in to space), CommonJS (Node still uses it, eventually will be deprecated), and the ES6 way of import and export (great, this is the thing going forward). The only thing to note here is a different syntax for importing and exporting modules if you use CommonJS. The reason why there was three ways of doing import/export is because JS didn't use to have one defined in the language so people used their own. Webpack: is a utility for being able to use modules in JS. You define the importing/exporting in your code (either CommonJS or the ES6 style) and Webpack will read the import/export syntax and transform it in to one nice usable file. You see, browsers still don't support actual modules in javascript, so tools like Webpack, Browserify, JSPM, and any others let you write code that uses modules while developing, but then transforms it all in to one nice file that you bundle in your website when you deploy it. The nice thing about Webpack is that it doesn't just stop at being able to import and export code, but you can also require css files and even images. This is pretty nice so you can easily tell where a CSS file is actually being used (and don't have to have just one big CSS file with all of the rules for every single page, or have a whole bunch of small ones that your browser would have to request one by one. Browserify: Competitor to Webpack, I forget what's different, just flip a coin (don't do that, just use Webpack) and stick with one. SASS: CSS preprocessor and a language that expands on CSS. Plain CSS is missing some nice constructs and SASS satisfies an itch of nice things such as nested CSS rules, and variables. JSX: only used with React.js (competitor to Angular made by Facebook), otherwise you'll never have to know it. In case you're curious, JSX is a sort of templating language used in React applications that looks like HTML but really gets transformed in to simple Javascript, also the templating is inside your code files instead of being in a separate file (like an .hbs file if you were using Handlebars for templating or whatever Angular does (just uses HTML as an extension but throws a bunch of templating on top?)). React.js: Competitor to Angular made by Facebook, but toned down to mostly just a view layer. It's quite well made but if your team is already using Angular you might as well stick with it. Hot-reloading: I forget exactly but it's like having your browser automatically reload when changes are made to your code, but hot-reloading specifically I think goes further and doesn't refresh the page -- just updates the resources and leaves you in the state you were in, so you don't have to click through your UI to get back to where you were each time you make a change. edit: This talk may help with figuring out Webpack: https://www.youtube.com/watch?v=VkTCL6Nqm6Y It's a few years old now so some things may have changed, but it goes over the core of what Webpack is about and why you'd use it. piratepilates fucked around with this message at 21:36 on Nov 12, 2016 |
|
#
?
Nov 12, 2016 21:10
|
|
|
piratepilates posted:
I've been programming for something like 20 years, but I've stayed pretty much completely out of the web domain. At the most, I had conjured up an ASP.NET REST application to gather some data for us. I was about to do something in Django and keep it static. However, I found out in the larger organization at work that we have a handful of people that have used Django in tandem with contemporary technologies. I decided that I wouldn't have been the first to push us this way, but I'd be the second if I could help it. So now I'm going all-in. We're not a software company, so that should explain how we could get away with this.
|
|
#
?
Nov 12, 2016 21:53
|
|
|
piratepilates posted:
Browserify was never really meant for actually bundling applications, it was meant to wrap around CommonJS (Node) modules, and make them work in the browser without rewriting them (hence the name). It ended up being useful to then just write all your web code as CommonJS modules and package everything at once, but it wasn't really meant for that. Webpack was more specifically made for that purpose. Rocko Bonaparte posted:Haha I'm hosed. I don't even know what any of those technologies are that all three of you posted. Okay--I am trying to use Angular, sure. There's one. And I get partial credit for JS, HTML, and CSS. But the others? Ugh. Do you NEED to use Webpack? It won't be terribly useful for Angular 1.x. There are a number of tutorials on how to use it with Angular 2.0, but I wouldn't bother if you are using 1.x, I'd just do a manual concat of your JS files.
|
|
#
?
Nov 12, 2016 22:51
|
|
|
Thanks for this summary. This helped me grok a bunch of things I've never used.
|
|
#
?
Nov 13, 2016 06:37
|
|
|
piratepilates posted:Babel.js: JS is an interpreted language and browsers only support a certain version at a time. Babel is a utility for taking code written in certain versions and transpiling them to be able to run in another version. The most common was ECMAScript version 6 to compile to ECMAScript version 5, but now (new/current) browsers mostly support ES6. There's like no competition in this space, and you should always use Babel. disagreed. babel is an overcomplicated monster which will blow up your node_modules by tens of thousands (!) of files. babel 6 in particular suffers from second-system and is flexible beyond reason. if you want to compile stuff to es5 i recommend typescript in --allowjs mode, or maybe traceur
|
|
#
?
Nov 13, 2016 06:41
|
|
|
Alternatively, babel is fine. I mean I use it on every project and it takes like 3 config lines to get it going and then I don't ever have to think about it again.
|
|
#
?
Nov 13, 2016 06:59
|
|
|
Gul Banana posted:disagreed. babel is an overcomplicated monster which will blow up your node_modules by tens of thousands (!) of files. babel 6 in particular suffers from second-system and is flexible beyond reason. if you want to compile stuff to es5 i recommend typescript in --allowjs mode, or maybe traceur Oh that's true I forgot about Traceur, and if you're starting a project where Typescript is easy to use then you should definitely definitely use it. If it's something where Babel is set up by default (Ember-cli, and maybe react-create-app?) then Babel should be fine anyway, even though it's gotten weird it should be simple enough to get it set up in a way that will work for you.
|
|
#
?
Nov 13, 2016 08:21
|
|
|
Thermopyle posted:Alternatively, babel is fine. I mean I use it on every project and it takes like 3 config lines to get it going and then I don't ever have to think about it again. last time i used it, it was indeed three lines of config. but then i had to think about it again when every project build in the solution took ten seconds extra to scan the filesystem, and every CI build involved downloading an extra 80,000 javascript files
|
|
#
?
Nov 13, 2016 10:16
|
|
|
Well, I was going to be seeing if the AngularJS Hello, World thing that I was slapping together post-Webpack works on Monday. If that all seems fine and I appear to have ironed out my issues with Webpack, should I just leave that all there? The site I'm working on is basically a glorified table with verbose views. I wouldn't consider it a huge thing, so it doesn't sound like Webpack is that useful. However, the tutorial I was using it with was including a linter step in the pack process that looks really nice to have as part of the CI process. So I'm kind of torn.
|
|
#
?
Nov 14, 2016 00:55
|
|
|
Well, I got the basics up and running. I managed to soldier through the full-enterprise stuff in the tutorials I was reading. I heard that there are some JavaScript frameworks out there that can handle presenting tabular data very easily. Most of the stuff I have to show is tabular in some fashion. What should I be looking up? I need something where I can search the data, scroll through it, select and reposition column headings, and tag some to be put in something like a shopping cart. I imagine I can doodle all this, but I heard there was some stuff that can consume a REST API and cram that poo poo into pretty tables for me already.
|
|
#
?
Nov 14, 2016 21:16
|
|
|
Rocko Bonaparte posted:Well, I got the basics up and running. I managed to soldier through the full-enterprise stuff in the tutorials I was reading. I heard that there are some JavaScript frameworks out there that can handle presenting tabular data very easily. Most of the stuff I have to show is tabular in some fashion. What should I be looking up? I need something where I can search the data, scroll through it, select and reposition column headings, and tag some to be put in something like a shopping cart. I imagine I can doodle all this, but I heard there was some stuff that can consume a REST API and cram that poo poo into pretty tables for me already. I would imagine there are probably a bajillion Angular components out there that do this, so look for one(s) that are popular and maintained on github! That is, if you are indeed using Angular, which I think you are. https://www.google.com/search?q=angularjs+table+component
|
|
#
?
Nov 15, 2016 01:19
|
|
|
Lumpy posted:I would imagine there are probably a bajillion Angular components out there that do this, so look for one(s) that are popular and maintained on github! That is, if you are indeed using Angular, which I think you are. I've wound up using Smart Table for now. Then I threw in angular-ui to get a modal window. That is not working and I don't know why. I trigger it, and instead of getting a modal window, it shits out the modal's HTML at the top of the page. I look in the DOM and I see all this stuff spring up in it to actually launch the modal. However, it doesn't actually do it. I added the angular ui template module and added the bootstrap stylesheet, but it still blows me off. Google Chrome doesn't complain about anything in the debugger. Any ideas? Regardless, I guess I'm at the point where I should sit down with a book or whatever and get the basics down of Angular. I have been just faking it at this point, but it's time I figured out the basic logic behind it.
|
|
#
?
Nov 16, 2016 00:23
|
|
|
|
| # ? May 22, 2024 08:30 |
|
|
Rocko Bonaparte posted:I've wound up using Smart Table for now. Are you sure you included the styles for angular-ui? Creating a modal IS basically making GBS threads out the HTML attached to the body or html element, but if it isn't styled, it won't look like anything remotely resembling a modal dialog box. Also, feel free to PM me any questions about Angular, half my day job these days is answering questions about it.
|
|
#
?
Nov 16, 2016 01:23
|
|