|
Is the official angular "phonecat" tutorial out of date / broken? Step one is to launch the node web server in angular-phonecat/scripts/web-server.js, but the file doesn't exist: https://github.com/angular/angular-phonecat/tree/master/scripts Any other good angular tutorials someone can recommend? (bonus points for angular + node) This is the best one I've done so far, but it doesn't get into much detail: http://scotch.io/tutorials/javascript/creating-a-single-page-todo-app-with-node-and-angular
|
# ? Apr 1, 2014 13:42 |
|
|
# ? Jun 5, 2024 20:16 |
|
fuf posted:Is the official angular "phonecat" tutorial out of date / broken? Bookmark this page: https://github.com/jmcunningham/AngularJS-Learning If you're using Node you probably want to look at the whole MEAN stack (MongoDB, ExpressJS, Angular, NodeJS). ExpressJS will save you a lot of time setting up your back end. Google MEAN stack tutorials and you should be able to find quite a bit about it with examples.
|
# ? Apr 1, 2014 14:29 |
|
excidium posted:Bookmark this page: https://github.com/jmcunningham/AngularJS-Learning oh dang that's a lot. Thanks. I've been learning the MEN bit of MEAN for a while, but I never really understood what angular (et al) were for. Then I realised I was writing a lot of messy jquery to update html elements without refreshing the page, and something finally clicked.
|
# ? Apr 1, 2014 15:10 |
|
fuf posted:Is the official angular "phonecat" tutorial out of date / broken? I think said web-server.js is installed via an npm package, did you run npm install?
|
# ? Apr 2, 2014 18:37 |
|
Is there any sort of 'common method' of building somewhat complex CRUD and tabular data interfaces? I'm currently trying to add a CRUD for a recently-created table with some in-place editing, and I'm frustrated because I feel like I've done this before but haven't really come up with a good way of reusing any of my code. I'm using Angular, and aside from keeping some basic components, I feel like I have to do a whole bunch of work each time: set up the basics of my API, set up a template that matches said API, wire up a bunch of sorting/filtering, create a bunch of functions for any editing functionality. Am I doing something wrong?
|
# ? Apr 3, 2014 16:12 |
|
Use a grid component of your choice? It is indeed a common thing.
|
# ? Apr 3, 2014 20:34 |
|
Mr. Wynand posted:Use a grid component of your choice? It is indeed a common thing. This reminds me. I'm getting ready to do a UI that will have a ledger in like Quicken or whatever. Anyone know of any good components out there made for this, or easily adaptable to it? I've been putting it off because I don't really want to build it.
|
# ? Apr 3, 2014 21:53 |
|
Spraynard Kruger posted:I think said web-server.js is installed via an npm package, did you run npm install? Aha, you are kind of right. There's still no web-server.js where the tutorial says there should be, but I checked package.json and 'http-server' is in the dependencies (and can be launched with 'npm start'). In the end though I started working through this guide instead and so far it's pretty good: http://www.thinkster.io/angularjs/GtaQ0oMGIl/a-better-way-to-learn-angularjs
|
# ? Apr 4, 2014 15:04 |
|
Thermopyle posted:This reminds me. When it comes to grid controls, my favorite so far has been Kendo UI's grid control, but that's like saying my favorite bone to break is my little finger. Overall I think general-purpose grid controls typically indicate a lack of design focus, but if there's one good place for grid controls, it's in spreadsheet-like applications.
|
# ? Apr 9, 2014 21:48 |
e: Update -- Looks like I resolved it, see the one-line update at the end if you want Has anybody using knockout.js had an issue with observables not working properly? On certain page loads (if I don't wipe the browser cache) it will load the HTML before executing the javascript and all the data binds screw up. The foreach is screwed and what should be an empty observable array is shown as [object Object], etc. For example: code:
I assumed this is the result of knockout being loaded too late, except my load order is: jquery (hosted on google's cdn), knockout (hosted locally) and then my site's js including the code that initialises knockout. I've tried loading them at the start of the page and at the end, and with the libraries at the top and my js code at the bottom. I've tried shifting the asset load order around, moving things in and out of document ready, and I can't figure out any pattern to it. Even when I load the page in chrome incognito for the first time it has this issue. I checked the network log and they're getting status 304 (not modified -- signifies cached) but when I modify code it still has the same issue. I can't imagine the local browser is caching javascript variables between page loads but just to make sure I even set the self.AddedTagsArray to null and then .removeAll() before and after initialising the observable and it's still just throwing [object Object]. When you click on [object Object], which is a link as per the code above, this error gets returned: code:
Does anybody have any idea what this could be? There's nothing in the PHP error logs for the server (Debian running nginx/php, website is running laravel/jquery/knockout). I'm just scratching my head super hard because there are no errors in the browser or unloaded resources etc. It's not being cached because when I modify the source code I can see it being re-downloaded by the server. e: I'm doing some more tests now and for some reason when I add the knockout code to within document ready, document ready doesn't get executed -- I'm doing test variables outside and inside that block and the ones inside it aren't getting made. But when I remove it from the document ready block sometimes it works again, sometimes it doesn't, but when it doesn't work the other (non-KO) variables still get made. I'm still so confused... Here's the whole KO js just in case I'm doing something hopelessly stupid: code:
code:
e: Update -- Okay so a google search pointed me to requirejs and after 10-15 minutes of figuring that out and ensuring that my code wouldn't be executed until knockout was loaded, it's all working. Hooray! Sulla Faex fucked around with this message at 09:26 on Apr 10, 2014 |
|
# ? Apr 9, 2014 23:15 |
|
http://jsfiddle.net/fimiak/QSu2p/ This is why I think angular will succeed in the long term, or at least will never be dropped by Google. Its community is growing exponentially. An ng conference for Europe in Paris with all of the top guys was just announced.
|
# ? Apr 10, 2014 06:22 |
|
isochronous posted:When it comes to grid controls, my favorite so far has been Kendo UI's grid control, but that's like saying my favorite bone to break is my little finger. Overall I think general-purpose grid controls typically indicate a lack of design focus, but if there's one good place for grid controls, it's in spreadsheet-like applications. Greve posted:http://jsfiddle.net/fimiak/QSu2p/ I mean, angular is great, but other frameworks have their merits as well and it's a shame to see them not getting as much attention. Or, rather, I don't care that they don't get as much attention, but they get pretty much zero attention relatively speaking.
|
# ? Apr 10, 2014 17:19 |
|
Greve posted:http://jsfiddle.net/fimiak/QSu2p/ http://jsfiddle.net/nt5GA/1/embedded/result/ http://jsfiddle.net/nt5GA/2/embedded/result/ Is Angular used on anything public-facing or mission critical by Google? The better determinant of how much they'll invest is "how hard is it for them to get away from it/how much of their poo poo will break if they don't update it" not "how many people on the internet wanted to know what it was". I don't think it's really feasible to predict how companies will continue to invest, but aligning with their amount of self-interest is the best approximation I've found.
|
# ? Apr 10, 2014 17:58 |
|
Subjunctive posted:http://jsfiddle.net/nt5GA/1/embedded/result/ Still, Google's a company where their amount of previous investment isn't a great predictor of future use either. They put a lot of time into their batch search algorithms and dumped everything for Caffeine to get better real-time results.
|
# ? Apr 10, 2014 21:04 |
|
dumb question re: React - I have a page with a big table handled by React that need to be filterable by column. Using React I have methods that listen for filter add/remove events via pub/sub, but I need to have a UI to control adding and removing filters. I want to put the controls for the filters in a pretty distinct page element from the table (a jquery mobile panel, to be specific), so I feel like it would be awkward to expand the scope of the React element to including basically the entire page (I'm using jQuery Mobile for layout and controls). Can anyone offer some advice on how to handle this situation? This is my first time trying to implement React in production and nobody on my team has more experience than I do, but I do have a ton of experience with jquery mobile.
|
# ? Apr 11, 2014 03:16 |
|
Chenghiz posted:dumb question re: React - I have a page with a big table handled by React that need to be filterable by column. Using React I have methods that listen for filter add/remove events via pub/sub, but I need to have a UI to control adding and removing filters. I want to put the controls for the filters in a pretty distinct page element from the table (a jquery mobile panel, to be specific), so I feel like it would be awkward to expand the scope of the React element to including basically the entire page (I'm using jQuery Mobile for layout and controls). This is a good blog post to get into component thinking. Basically, the container is a component, and then you drill down to the smallest components, ideally those are reusable to the point the more granular they become, whether it's a widget or whatevs. http://facebook.github.io/react/blog/2013/11/05/thinking-in-react.html The key there is to figure out your hierarchy of state. This means establishing what needs to know what. In this instance likely your 'page' component handles the state, and then has sub components representing your filters and the table respectively. At that point, you give the filter component a link to pass state changes back up to the page component, and then that state works down to the table via properties. Does that make sense?
|
# ? Apr 11, 2014 03:47 |
|
Maluco Marinero posted:This is a good blog post to get into component thinking. Basically, the container is a component, and then you drill down to the smallest components, ideally those are reusable to the point the more granular they become, whether it's a widget or whatevs. Yeah that page helped a lot when i was getting going, i guess my faltering point is building the whole JQM page through React. The problem is that the filters need to be multiselects and are not children of the table, but need to have access to the full list of distinct values of the given column. I handled this through janky spaghetti code before but want to make things more modular now but don't know how to without tying everything into a huge (page) block, which is sort of the opposite of modularity as I understand it.
|
# ? Apr 11, 2014 04:32 |
|
Has anyone here migrated from knockout to react? I'm really liking the look of react and the component model looks much more sane than abusing the DOM for components. I'm having crashing due to out of memory errors on Safari IOS due to a hugely complex DOM, so that is my primary motivator for switching. Can anyone whose made the switch comment on performance gains? I'm assuming react has its own equivalents for observable arrays and computed observables? Or are they no longer necessary? I'll be prototyping this weekend so that should come yo light pretty quickly. Just curious about others' experience as react as quite a different architecture but it looks like you can have much better separation of view model and view.
|
# ? Apr 11, 2014 05:21 |
|
I'll make a big effort post about React component structure later if you like, including embedding inside other frameworks (I'm doing - in separate projects, embedding react in an angular structure, and react standalone, representing the entire application), just having family time right now.
|
# ? Apr 11, 2014 07:29 |
|
Misogynist posted:There's a lot of new development happening in Angular, including all their reporting interfaces for DoubleClick. It's not realistic to expect them to immediately drop all of their legacy code everywhere and switch their entire frontend paradigm for every one of their most mature applications.
|
# ? Apr 11, 2014 09:13 |
|
edit: lets try that with the right tags Now, this is all just from a guy using it, and I may be wrong on some things when it comes to the RIGHT way, but this is all coming from my experience so hopefully it's valuable. The React State What React is and how it handles state is probably the most important thing to understand coming in. In React state flows down from the root component. When you use React.renderComponent you feed it some properties and then from there it should be able to render everything below it, whether that's just a self contained UI Component or your entire single page app. So, properties and state are the way you represent the moving parts of your component. Properties are immutable, and state isn't. Usually state is passed down the component tree as properties, which basically means you use the state of one component as your source of truth, and let the sub components have that state through their properties. Where you put the state depends on what makes sense for your application. Using the application example of Chengiz, it's clear that most of the state will need to be held in a component that encapsulates the table and the filtering widgets. From that point, you pass the filtering widgets what they need through properties, and also handler that allows them to pass state changes back up the hierarchy. That would be bound with onChange or something, depending on how you're implementing your widget. A digression, implementing a jQuery widget If you need to create a custom select (common case), you might be using another library that works on HTML Select elements. That's not a big deal, ideally you should be able to create a normal <select> (or whatever collection of DOM elements required by the UI library), and then apply the methods on the DOM node during a componentDidMount method, which is the point where you can access the actual DOM nodes. Provided your library isn't mutating the mounted DOM node, they should play nice, as the library UI updates the select, and then your onChange handlers on the select then communicate the state up the tree. If that fails, you can still access the methods in componentDidMount to get your library to directly talk to the state. ...back to React state So you'd be passing information down to the widgets, those properties would likely be: - arrays of choices - onChange handler function, that will let the widget tell the root component about changes - current values If there was a little more complexity, say you had to press save to commit changes on the widget, then that widget would have it's own state, and the properties would contain initial values. When that initial value property updates you reset the state of the widget, but otherwise the widget can do it's own thing without being locked by the root component. Displaying View Data Usually the components that are displaying data, they should be just fed properties. What the data is. If you have controls outside that change how the data is presented, then you'd have that information as properties too, but otherwise it can be state on the display components. In the table example earlier, consider this setup: pre:- FilteringTableView (props: rawData) state: filters - FilterWidgets - (props: choicesFromData, onChangeHandler, filters) - DisplayTable - (props: filteredData) state: tableSortOrders If necessary you could take your components to an even more granular level with: pre:- DisplayTable - DisplayTableHeader - DisplayTableColumnHeader - DisplayTableBody - DisplayTableRow - DisplayTableCell Implications of React's State Model Now to answer your question ShaunO, React doesn't really have a concept of two way data binding out of the box, so the paradigm of observables doesn't really exist. What you have instead is a system that renders quickly, binds event handlers and then just sits there. As in, it's not running timers, watchers on variables, nothing. All it's doing is waiting for you to trigger some change in the system and then react to it (hence the name). If you want to have two way data binding, you take a DOM element and give it a handler that updates the state, and that's pretty much it. From React's docs: http://facebook.github.io/react/docs/forms.html JavaScript code:
There's a lot of ways to approach passing state to where it's needed, in one project I have a fairly complex page with lots of interactions that cascade throughout. In that case I'm using a controller object that essentially helps everything communicate actions which then get sent to the root component to trigger a rerender. The key thing is though, if you're limiting duplication of state by using properties, you're making it easy to keep the entire UI in sync because the state only exists where it makes sense to exist. React can do this very quickly too, because it does all the hard work in pure Javascript, and only talks to the DOM in one big optimised operation. Once it has rendered, the app is at rest, it doesn't need to keep watching, running timers or whatever because all it needs to know is when setState or setProps is called to start another render cycle. You can even get more performance out of it by using a shouldComponentUpdate function, which allows you to take the incoming props & state, compare them to the existing props & state, and decide whether or not a render is needed. In the right places that can mean React can skip huge swathes of the DOM on it's render passes. React and Arrays React keeps track of DOM elements and how they link to React Components via a html attribute, data-reactid. There's no other proprietary tags in use which is great for a semantic HTML output. Usually React automatically figures out the id based on a random one for the root, followed by a numeric sequence for every component inside. In the case of rendered arrays however it's recommended you use keys. Basically, that just means when you render an array of components, you give them a key, and that way React can know how to reuse those DOM elements when the Array gets reordered, rather than rendering the changes in a less efficient manner. You can do some really cool things with this that are much more annoying to reason about with Angular (in my experience with that), such as an infinite scrolling view that simply reuses all the DOM elements, cycling them as you scroll down while keeping them in view with translateY. If you handle the keys right you can reorder them or mutate quite efficiently, which means I can manage to get a huge array rendered on iOS, but only need to maintain 20 or so DOM children. React in a container This is pretty straightforward. Whatever you use as your view, say an angular controller or directive, or something analogous in your framework of choice, you just need to provide a DOM element and then render the root component with the appropriate properties. JavaScript code:
This is just a case of figuring out your state handling. As an example for my dedicated React App - my initial DOM is just a single div with the id of "<appName>app", and from there we have this component structure: pre:- App state: currentView - AppNavigation - ViewContainer(props: currentView (which is a component) ) There's probably a lot more I could talk about, or be more accurate in describing, but hopefully that gives you some useful info to chew on. Maluco Marinero fucked around with this message at 13:13 on Apr 11, 2014 |
# ? Apr 11, 2014 12:50 |
|
Wow, thanks for the effortpost. It does sound like I'll have to make the whole thing a react component, but knowing about setProps() is good. Somehow I missed that one.
|
# ? Apr 11, 2014 15:19 |
|
Awesome stuff Maluco, that helps a lot and clears up in my mind the 2 way property change pattern That gives me a good idea of how I might be able to port just the problem code to react for now to see if I get any gains
|
# ? Apr 11, 2014 23:49 |
|
ShaunO posted:Awesome stuff Maluco, that helps a lot and clears up in my mind the 2 way property change pattern Good to hear, we did exactly that with a project about 3 months ago. We were running Angular, and it just wasn't efficient enough once the data size of the document (deliberately vague due to the product being under NDA) grew to a certain size. Load times were at 45 seconds with some of my big test data sets, which were not 'that' big. Pulling Angular out of the core of the app's render, replacing it with React, got that speed down to 3 seconds. Admittedly there was some potential for optimising Angular but we were already way over the recommended number of watchers and optimising Angular tends to mean breaking what makes it simple to use, at least in my experience with it. I'd rather get to 3 seconds and then optimise from there (which we did), rather than try to shovel us out of a 45 second hole.
|
# ? Apr 11, 2014 23:57 |
|
Okay, buckled down and did the whole page with React, no problems with jQuery Mobile at all and it's really loving easy to modify.
|
# ? Apr 12, 2014 16:29 |
|
Chenghiz posted:Okay, buckled down and did the whole page with React, no problems with jQuery Mobile at all and it's really loving easy to modify. The reusability of React components makes it so that the further you get in to a project, where you've got your components mostly fleshed out, the easier it is to make minor or major modifications. Or at least that's what I've found so far in my couple of weeks with React.
|
# ? Apr 12, 2014 19:10 |
edit: Disregard this post, I just installed a knockout-specific debugging tool to chrome and it looks like knockout observables are actually working after all, it's just that everything I'm using them for is failing for some reason without a hard refresh. It could be that the page loads too quickly from cache and my code is loving up somehow as a result. I'll look into it. Okay so that Knockout problem I described earlier in the page never really went away, but it has stabilised -- on a hard reload (i.e. ctrl + f5) it loads everything fine. Every subsequent reload fails to process the knockout bindings - no observables, stuff that should be hidden by knockout isn't, etc. I've spent an hour or two looking into it and I've actually forced all javascript files (jquery, knockout, require.js, and my own custom scripts) to download afresh from the server using a cache-busting rewrite in nginx. Each js file is called using a _cache23587345.js where the numbers are randomised each time. code:
Anybody experienced anything like this?? I can't think of what's going on. Chrome dev tools don't show any problems with loading scripts etc, and there's no discernible difference between the load order etc in a normal (broken) load and the load after a hard refresh. Sulla Faex fucked around with this message at 12:13 on Apr 13, 2014 |
|
# ? Apr 13, 2014 12:08 |
|
I've had a look through this thread and online opinion and it seems that I have settled on the javascript framework I want to learn once I'm able to pick up javascript and a bit of jquery. The general consensus seems to be that ember is the one worth picking up. Having to put together all the separate components in backbone doesn't seem worth it (even though I favoured flask over django for this exact reason) and angular just seems a bit iffy in some of its design choices. However, while I've settled on one in terms of actual design and usage, it does seem that angular might actually be the one to pick for a newbie primarily based on its community support and the learning resources out there. There doesn't seem to be anything close to egghead.io and the thinkster.io angularjs tutorial for ember. So should I perhaps learn angular over js just because of the resources? It does seem that learning one should help with picking up the rest anyway.
|
# ? Apr 13, 2014 19:45 |
|
sharktamer posted:I've had a look through this thread and online opinion and it seems that I have settled on the javascript framework I want to learn once I'm able to pick up javascript and a bit of jquery. The general consensus seems to be that ember is the one worth picking up. Having to put together all the separate components in backbone doesn't seem worth it (even though I favoured flask over django for this exact reason) and angular just seems a bit iffy in some of its design choices. Or, learn Ember and document your experience, creating the resource the Ember community lacks. I'm starting on a series of articles called "Watch Me Try And Figure Out...." that is going to be Backbone / React, mainly because I learn best by explaining things to others, even if the "other" is a text editor / pretend readers.
|
# ? Apr 13, 2014 22:01 |
|
Just one thing to keep in mind, recommendations are typically subjective. There isn't really one MVC framework to rule them all because they all use quite different structuring and concepts, and as a result are suited to different approaches to building applications. Furthermore, if you're just coming in, you're likely to be learning a lot more than just the framework, but also finer points of JavaScript and what not. If that's the case I strongly recommend you just dive into which ever one feels clearest to you, whether that's because of good design, or good documentation. You're not going to be able to correctly appraise the long term limitations or benefits choosing framework X over framework Y, hell, even experienced teams have trouble picking a winner the way the ecosystem is populated right now. If you feel like you can get a toehold in Ember, something working and you like the feel of the code, go for it. At this point you most benefit by building and learning and not getting hung up on the choice. I rag on Angular because I feel it has too low a performance and maintainability ceiling compared to React, but that's just for the way I'm building my apps and the kind of use cases I'm working on. Angular is a strong choice for a lot of other people and gets the job done for them. I imagine Ember is the same for those who swear by it.
|
# ? Apr 14, 2014 02:03 |
|
Lumpy posted:I'm starting on a series of articles called "Watch Me Try And Figure Out...." that is going to be Backbone / React, mainly because I learn best by explaining things to others, even if the "other" is a text editor / pretend readers. I would actually really like to read this series.
|
# ? Apr 14, 2014 06:32 |
|
Same here! I use Backbone at work and at home so I'd love to see how it works with React.
|
# ? Apr 14, 2014 14:10 |
|
Kobayashi posted:Is there any kind of super-light, file-based database I can use with something like Node? I ask because I do a lot of prototyping. I deploy to a lot of different environments that I do not control. Anything that reduces the number of dependencies I need makes my life so much easier. I don't care about performance, scalability, or even data integrity, really. I just need something that looks vaguely like a DB that I can use for prototypes. Following up on this. Some context: I'm a designer, but I like to prototype when I can. I don't write production code, and I never will. With that said, I'm trying to gradually improve my prototyping skills. For me, that means moving from strictly client-side prototyping to some client+server prototyping. I've latched on to Node because it's Javascript and that's a language I'm already learning. I tried to pick up Rails once, but learning an entirely new language on top of a entirely different paradigm was too much. Node lets me vomit out code that approximates my design concepts much more quickly than if I had to learn a new language. Back to databases. Bare with me, because I don't know what I'm talking about. Originally, I was using Local Storage. Then, based on the advice from the tread, I whipped up a simple CRUD API using NeDB, which describes itself as "SQLite for Node.js projects," with an API that "is a subset of MongoDB's." It was really easy to use, and makes a lot of intuitive sense to me, until I start to think about relationships (which, as Mr. Wynand points out, is 99% of even silly little prototypes like mine). From what I can tell, I have to do a lot of the "relational" part myself: Either by maintaining multiple files, or by serializing the relationships inside each record. To me, it seems like NeDB isn't really SQLite at all, except in the sense that it is file-based. Now I think I should just go back to something like Node-SQLite. But, what gives me pause is how much more difficult the syntax seems to be. Instead of an API, it looks like I basically construct query strings and pass them to the DB. It seems like I'm missing something, because it looks my choices are either 1) a nice, easy-to-use Javascript API, but a database that doesn't really deal with relationships or 2) lots of string manipulation. So I guess my question is, am I misinterpreting how relationships are modeled on the NeDB side? Alternatively, am I missing the API layer for the SQL side? Or perhaps I just need to harden the gently caress up?
|
# ? Apr 16, 2014 18:25 |
|
Kobayashi posted:Now I think I should just go back to something like Node-SQLite. But, what gives me pause is how much more difficult the syntax seems to be. Instead of an API, it looks like I basically construct query strings and pass them to the DB. It seems like I'm missing something, because it looks my choices are either 1) a nice, easy-to-use Javascript API, but a database that doesn't really deal with relationships or 2) lots of string manipulation. So I guess my question is, am I misinterpreting how relationships are modeled on the NeDB side? Alternatively, am I missing the API layer for the SQL side? Or perhaps I just need to harden the gently caress up? Those query strings you speak of are the SQL language, and for better or for worse pretty much all relational databases work with some flavor of it. Although the syntax might not be very pretty and often counter-intuitive, the core structure of it (conditions, joins, selects etc) is more or less just relational algebra which, barring some unfathomable advance in theoretical mathematics, is the be-all end-all model of working with relational data, period. Point being: it may look weird, but it's actually the best way of doing those sort of things. But anyway, you don't need to worry bout any of that - as you suspect, you are indeed missing an API layer here, usually you don't have to work with SQL strings directly (and there are in fact good reasons you should actively avoid it) - the thing you are missing is an ORM library. I don't have any specific experience with node ORMs but it looks like there's no shortage of them. You'll be able to just work with JS objects. The SQL strings are still going to be there, and it's good to remain peripherally aware of that fact, but for the most part it will just be magic "put object into database" -> "get object form database" and most will let you set up relations and stuff without getting too bogged down with joins and stuff, at least for the trivial case. I know this is just for prototyping and whatnot but I really thinking picking up some SQL basics is going to serve you well over the very long term, even if you never ever write production database code. It's not really that complicated a model but it's extremely powerful and widely used, it's going to help you make sense of a lot of stuff.
|
# ? Apr 16, 2014 18:55 |
|
Mr. Wynand posted:Those query strings you speak of are the SQL language, and for better or for worse pretty much all relational databases work with some flavor of it. Although the syntax might not be very pretty and often counter-intuitive, the core structure of it (conditions, joins, selects etc) is more or less just relational algebra which, barring some unfathomable advance in theoretical mathematics, is the be-all end-all model of working with relational data, period. Point being: it may look weird, but it's actually the best way of doing those sort of things. ORM, fantastic. That was the term I'm missing, thank you. As to your larger point, sigh, I know, you're right. In fact, I've actually taken a database class before, years and years and years ago. It was the course that convinced me that computer science was not for me. So while I have a passing familiarity with the terms you mentioned, my knowledge is so calcified as to be basically useless. My hope is that an ORM library allows me to ease my way back into databases while still affording some degree of productivity.
|
# ? Apr 16, 2014 19:14 |
|
This is a really dumb question but I am having a hard time figuring out how to approach finding a solution. How do I get local information onto a website in real(ish)* time? A toy example: I have an ubuntu machine that is currently hosting the default "It works!" apache homepage; the same machine is also running a python script that communicates with an external temperature sensor. I want to host a website that updates the temperature as it changes (without refreshing). How do I bridge the information from python (or some other language if it is more convenient, idgaf) to a website? I am pretty sure the answer is some kind of javascript library, but I can't figure out a concise way to describe (and then google) this problem. *500ms of latency on a LAN would be ideal but longer turnaround times would not be the end of the world.
|
# ? Apr 16, 2014 22:25 |
|
Kobayashi posted:ORM, fantastic. That was the term I'm missing, thank you. I really think you should look into using Rails (Ruby) or Django (Python) if you get a chance. They have ORMs, and are well suited to a beginner easing themselves back in to things because there are shitloads of decent tutorials, and the core they're built on is well established and developed. The problem with node is you're much more likely to have trouble with dependencies, changing APIs and much weaker documentation, which could prove to get in the way. Up to you of course, but personally if I'm doing thick front end, thin back end I'll use Django and the Django Rest Framework (extra package) that means I can express my data in simple terms, setup serialisers to go from Python to JSON and be done with it with a minimum of code, all reliable.
|
# ? Apr 16, 2014 22:43 |
|
Corla Plankun posted:This is a really dumb question but I am having a hard time figuring out how to approach finding a solution. http://socket.io/ https://github.com/abourget/gevent-socketio purports to be for Python, but I haven't used it. The LearnBoost guys are pretty smart, though, so I'd be optimistic.
|
# ? Apr 16, 2014 22:46 |
|
Corla Plankun posted:This is a really dumb question but I am having a hard time figuring out how to approach finding a solution. code:
|
# ? Apr 16, 2014 23:03 |
|
|
# ? Jun 5, 2024 20:16 |
|
ManoliIsFat posted:I don't know if you really need to get deep in to sockets... I agree with you 100% for this example, but I think sockets is right for a particular extension of the example that I had in mind. Thanks y'all! If I make something cool I will report back.
|
# ? Apr 16, 2014 23:47 |