terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›4 »

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

There's still scripting under the hood of Maven, something has to issue the commands. You're still aiming to be declarative in Chef, Puppet, Ansible, but at some point there has to be logic, someone has to write that logic and test it.

Ideally you get to the point where you're just using the declarative bits from day to day, but that's a poo poo tonne of plugins to be written before we get there as a default for new organizations.

# ¿ Oct 10, 2014 02:22

Adbot: ADBOT LOVES YOU

# ¿ May 11, 2024 10:41

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Shaggar posted:

well not in a plang makes it superior but its in a real repo system as in nexus which is designed for maven as opposed to "well, this unfinished thing is in our github. you can google it"

Dare I say a package system

# ¿ Oct 10, 2014 03:27

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

syntaxrigger posted:

same

does anyone have any pointers on how to steer a programming career? I am poo poo at everything and interested in most things, have trouble deciding what to focus on but I can't keep this Jack of All trades crap up for too much longer.

I'm a freelancer but I've been thinking about this a bit, and the kind of jobs I want to do. I started up as a PSD chopper, but really my focus is on being a front end developer for mobile web apps, and basically that's what I do now. Laugh if you want cause I'm a terrible web dev, but I'm a terrible web dev seemingly in demand.

Anyway my MO is to take jobs that scare me, that have big quotes, whether its an interesting technical problem that furthers my area of expertise, namely thick front end web apps, or just some intense clients with exacting standards.

Either way, I think the jobs you take should make you a little bit nervous. The fear is there because you know you're capable but you might gently caress it up. Being scared of failure can produce your best work as long as you don't be stupid. (agree to unrealistic deadlines, mismanage clients, etc)

So for me, its to seek out hard work and ignore easy money churns, it was hard to do for a while because I have to support my family, but its paid off so far. Might not be rolling in cash but I'm turning into the developer I want to be whilst not starving so hooray I guess.

# ¿ Nov 4, 2014 21:25

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Bloody posted:

im the software developer capable of quoting realistic deadlines

There's ballpark and there's stupid razor thin, and that's all part of the negotiation process.

# ¿ Nov 5, 2014 00:33

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Ansible only requires python on the remote as far as I know.

# ¿ Nov 14, 2014 06:59

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

lmao at the the people who think webapps have trouble with drag and drop. Webapps ain't perfect but if you're gonna sling mud maybe know a bit, anything at all, about the platform you're slinging mud at.

# ¿ Dec 5, 2014 20:57

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Power Ambient posted:

react.js is really cool. ok bye

# ¿ Dec 5, 2014 21:49

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

hobbesmaster posted:

why don't more people use mercurial?

Unless there's some hidden warts in Mercurial that I'm not aware of, it feels like its largely cultural at this point. The CLI is sane, and it still handles much of the stuff but does, but there's no Github for mercurial, Bitbucket did it but not before git through Github solidified as the defacto version control system for new open source projects.

# ¿ Dec 6, 2014 20:27

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

What is the practical reason for using week years? Financial or some such?

# ¿ Dec 29, 2014 08:53

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

kalstrams posted:

is dvorak/colemak something to look into or not

I changed to Dvorak well before I was doing paid development work, or just needing to be productive in general. I mean, It didn't take too long to speed up, but it's a pretty drastic change and it will hurt your productivity badly while you're making it. I like the layout, but yeah, big outlay.

All that said, I'm a wierdo who is using Dvorak, a trackball, vim, and terminal for everything.

# ¿ Jan 19, 2015 20:50

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

gonadic io posted:

if young: gauged ears? if old: long grey hair?

What are gauged ears?

# ¿ Jan 19, 2015 21:01

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I may be due for my mid life crisis but I'm not even 30.

# ¿ Jan 19, 2015 21:09

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I have to say I don't really get the value of DI annotations as they're usually presented in JavaScript frameworks. Typically the prototype to receive injection has string annotations, I guess I just don't see the benefit of declaring dependencies like that if you want to be able to control it from the outside. Sure it'll save you time while you're wiring it up, at least a little bit, but there's no easy place to go and see what gets injected where.

Maybe I'm the horror, but I set up something like this in a recent project, where you register classes under a string name with a class. newWith is how its gets instantiated and by default they're singletons, which was overridden in the last call to be instances instead.

JavaScript code:

 


world.register("comms", Comms).newWith();

world.register("planes:location", LocationPlane).newWith();
world.register("planes:form", FormPlane).newWith();
world.register("planes:user", UserPlane).newWith("comms", "actors:location", "actors:tickets");
world.register("planes:tickets", TicketsPlane).newWith("comms");

world.register("lookouts:app", AppLookout).newWith("planes:location", "planes:user").instances();

And tbh I didn't mind the little workflow of having to inject my new component into this wiring file. The things being injected are just ES6 classes with no dependence on the DI, so if I wanted to change strategy I can do it all here and be done with it. As I said, maybe there's something I don't get about DI but this feels like its reliable enough for my purposes.

Edit: only just realised how bad the cp of code was, but hopefully you get the idea

Maluco Marinero fucked around with this message at 09:10 on Jan 21, 2015

# ¿ Jan 21, 2015 08:11

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I guess I don't understand. Each of the 'classes' provided work just fine without this world context. They're just ordinary constructor functions that return objects. They can be passed mocks of the dependency they expect, the real deal, etc.

My confusion is this, ostensibly a number of claiming to be DI patterns, including Angulars and di-lite, ask you to declare whether its a service, factory, controller, etc, and declare all dependencies as strings. How is that not coupling your implementation to your dependency injection.

By specifying all that, you're requiring all pieces of code to identify themselves by a string and then trusting the big DI container in the sky to sort it out, aren't you?

If you mock out elements here, you still need to know the interfaces you're mocking, you still need to know the string identifiers if you use the DI context rather than calling it directly.

So at this point, I'm wondering where is the time saved. If you need to use modular components they still have to declare their dependencies if that's the approach used.

To be honest, I think I'd understand better if there was something people could point to as a reference library, ie, this is what a good dependency injection library looks like.

# ¿ Jan 21, 2015 11:53

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

uncurable mlady posted:

i might start using emacs with evil mode

Yeah I might try it out. My artisanal vimscript plugins are not very nice to work with/configure at times, if Emacs can get the best of both worlds, without sacrificing modal editing I'd be down.

# ¿ Feb 7, 2015 16:39

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Shaggar posted:

do you guys use any javascript routing libraries and if so which ones?

https://github.com/flatiron/director suits my needs but I don't do anything particularly complicated, mileage may vary and all that. Supports html5 push state and hashroutes/real routes, although I've only been using hashroutes for my stuff.

# ¿ Feb 10, 2015 17:50

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Hed posted:

This is from way back but I've done something like this in the past:
Python code:
def get_env_setting(setting):
    """ Get the environment setting or return exception"""
    try:
        return os.environ[setting]
    except KeyError:
        error_msg = "Set the %s env variable" % setting
        raise Exception(error_msg)

# then later...
DB_PASSWORD = get_env_setting('DB_PASSWORD')
This way you don't ever check passwords into CM. If an attacker can read your environment anyway then you've already lost. Bonus points for subclassing Exception into a more useful error.

Yeah, this is the way I do it. Any instance specific settings go into a config.env file, that I can even isolate to just the run with:

code:


#!/bin/bash

export $(cat config.env)
exec ./run_my_dumb_application

I dunno if there's a better way to do go about it, but hey, every programming lang has ways to get environment variables so no matter how a web framework or library implements their config, there's probably a way for me to get those environment variables in there.

The config.env is just a simple line of environment variables:

code:


FOO=thing
BAR=anotherthing

Maluco Marinero fucked around with this message at 05:51 on Feb 23, 2015

# ¿ Feb 23, 2015 05:49

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

my stepdads beer posted:

embrace vertical integration and face to the orm (django)

i really don't think there's a good way to do migrations well in a language agnostic way pls correct if wrong

The way I'm doing it for one project (haskell, im a bit loco) is to use liquibase standalone for the migration management. Its nice because I can write the migrations as straight SQL with rollbacks, and also have multiple apps with different named migrations that don't collide with one another, yet it's not tied to a particular language.

That said I'm generating a complete schema from my code so that I can be sure everything is set correctly on the real migrations. In my code I'm specifically not using an ORM, just a mapper that let's you write type safe queries that map to data types.

# ¿ Mar 6, 2015 10:45

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Except with type checking you're more likely to discover the error/collision at compile time, making it not nearly as risky a wildcard python import.

# ¿ Mar 10, 2015 10:36

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Yeah, the side project interview has all the same problems as getting a job through hackathon/open source/body of github work.

While it can be a valid method of discovering someone, expecting it as a primary method of gauging technical ability is just discriminatory.

# ¿ Mar 21, 2015 23:03

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Subjunctive posted:

that's interesting. I think our first major users of react were a) the mostly widely used page on our site, news feed, and b) the customer-facing tools through which most of our money comes in, ad management. I don't know how hard it is to use angular as part of something (like a new gmail widget or some part of news); that aspect of react really helped accelerate adoption, because if we'd had to convert all of news feed to react before we deployed any of it lolwutimo.

Yeah, that's a HUGE part of the leg up for React in my mind. With React it's actually really practical to eat an application from the inside, because wrapping components with more components is trivial and easy to do as long as you have good property flow.

On the contrary, Angular requires special snowflake HTML, comes with a router, and is quite controlling when it comes to SPA. The result is you go full Angular straight away, but even then the directives, controllers and services combine to create an application that's way less composable.

On another note, a colleague and I built a client services site using Django with Node as view renderer (using Jade and React static renders). With out next go around I'm keen to actually write it in React entirely, all the way down to the full layout. (we can even pretend we're using Jade with this https://www.npmjs.com/package/react-jade-transformer)

That way its trivial to turn any part of the site into an interactive component without trouble. Try doing that with Angular. The fact that React is versatile, isomorphic and can produce compliant markup is huge.

Its nice to know also that no React = no Facebook, because going all in on a technology has its risks of course.

# ¿ May 6, 2015 23:33

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I'm a terrible web developer and I use Vagrant + Virtualbox. anyone have experience with VMware in place of it, especially whether it's worth the price premium. always feel like file system is a little sluggish when it's on a Virtualbox VM.

# ¿ Aug 6, 2015 02:28

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

I'm aware of the price premium, almost $350 AUD a seat, but the question is whether that price premium is worth it for the performance gain. I have no qualms building up a couple of boxes and provisioning if the performance increase is high, as I say development is noticeably sluggish in a Virtualbox environment.

# ¿ Aug 6, 2015 10:52

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

http://macaw.co costs moneys but is wysiwyg.

or you could just make a http://motherfuckingwebsite.com

# ¿ Aug 6, 2015 12:46

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

speaking of spreadsheets, it reminds me of this dumb thing I made so I could unit test my calculations against a spreadsheet, for a project where I was implementing analysis on observation data.

https://bitbucket.org/MalucoMarinero/cellacceptance

turns out the algorithms they gave me were wrong and they're having real trouble replicating old results they got from fortran and compiled code.

science!

# ¿ Aug 19, 2015 23:59

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Shaggar posted:

step 1) use stored procs. all ur problems then go away. that's it. theres no more steps

So cause I'm a dumb web developer whom cut their teeth on Django I've never really worked without an ORM or statement mapper, but writing stored procs for all data access sounds pretty appealing. That said though, what's the right way to go about managing that code base, I mean I assume the stored procs get written + updated during your schema updates, but are there documented approaches to organising it all when it gets to non-trivial sizes?

# ¿ Aug 22, 2015 07:02

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

pepito sanchez posted:

i've looked into react, and with the development of relay it just made me more curious. the idea of representing the UI as small maintainable and extensible pieces is cool. the biggest downside i read about was how heavy it is for larger sites. something about how it uses a virtual DOM before transitioning over to the DOM. i assume that facebook's main page actually implements react, and it's not exactly the quickest load in the world. thoughts?

It is faster than Angular, hands down. You can get around the initiation time of Reacts initial render by prerendering it on the server, but once you're in a view with mutations, it'll do it faster than Angular in most cases. The only reason ANgular would feel faster in an initial render is because the templates are DOM, so it can render that DOM straightaway, but the bootstrapping process of actually taking data and turning it into stuff is still slow in Angular, especially with a lot of data binds. The virtual DOM is a far faster way to perform mutations, which is why everyone is copying that approach now (Ember, Can.js, mercury, riot, etc etc)

# ¿ Aug 28, 2015 01:37

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

pepito sanchez posted:

assume you have absolutely no control over the backend. is this kind of stuff still possible from the front-end or do i have to depend on the server rendering my views? sadly my *actual* work involves a genexus backend, something i can't touch and they are terrified to touch because it's literally purely generated magic code that can't be touched. angular has been the option because nearly everything worth mentioning is done from my station apart from design, and the only thing i send to the backend are ajax calls. i'm really looking forward to next week's job fair at college. this will sound horrifying, but please let me work with a ruby dev instead.

fast edit: i already know knockout is faster than angular, specially with require.js. i don't think that's the same for react, but that's only from what articles i've seen. it's not so much about speed for me, but a specific need of convenience, maintainability, and limiting headaches.

No. React IS faster than Angular, but it depends on what you're using it for. If the backend is basically all JSON, go for it with React, but if Angular is working for you don't uproot all your code. That said, you can just bind React components from say an Angular Controller, but then you've just bloated your code with two big libraries/frameworks. In an app I'm working on we had to do that because Angular was abysmally slow on a critical part of the app, and we're gradually phasing that out so it's all React. You don't need server side rendering to do React, but it's a great way to take the bite out of initial page load, which is something EVERY non-trivial single page app will suffer regardless of framework.

# ¿ Aug 28, 2015 02:53

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

MeruFM posted:

although the bottom 20% of developers is often actively bad for the code base and cause more issues than they fix going forward.

How can this be so though, what organisation is hiring people with absolutely no reviewing of work, or pairing, or communication?

If lovely developers can sink the ship, surely there's a lot more lovely developers and development processes in place already?

# ¿ Sep 13, 2015 08:39

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

GOTO second paragraph I guess then. If companies can't figure out to grow talent through review and collaboration then they deserve a shortage of effective developers.

# ¿ Sep 13, 2015 09:13

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

fleshweasel posted:

sorry, we're looking for someone who already knows the answer to this stupid loving puzzle

Riddles in the dark, silly con valley style.

# ¿ Sep 24, 2015 02:17

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Eh, Ive seen checked in and deployed code that had a 400 response come back with "gently caress you" in the body. I guess some developers need rules. :P

# ¿ Oct 26, 2015 00:36

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Jabor posted:

im the deploy from sotoyamashita

loving SPICY HALF-DONE RAINCOAT MEMES

# ¿ Oct 26, 2015 03:14

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Soricidus posted:

what better thing is there to do with your life, than to spend it doing things you enjoy

and how is it bad if people are even willing to give you money to do the thing you enjoy, so you can do more of it in your limited lifespan

Yeah, I've met people who see working as nothing but a means to earn 'fun tickets' (money), but they were dour as gently caress.

If something I enjoy doing is self subsidising, then great.

# ¿ Oct 31, 2015 21:51

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Mate, even if you're self employed your clients or customers are setting requirements and timeframes for you. You're never actually free from all your criteria unless you literally never promise to do anything for anyone ever, paid or not. Which is fine if you want to roll that way, but the likelihood that you can operate like that and work on projects of consequence is pretty slim.

# ¿ Nov 1, 2015 03:45

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Notorious b.s.d. posted:

yeah i actually want to have total latitude in my activities

why should i even want to work on "projects of consequence" that are not my own projects?

Even if they are yours, they don't actually work like a dictatorship. You are as beholden to the people you lead as they are to you in your own projects.

# ¿ Nov 1, 2015 03:54

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Notorious b.s.d. posted:

those relationships are still fundamentally different

we are not pulling together to increase the capital stock of some dude on a yacht somewhere. shared sacrifice to serve shared goals, not externally imposed conditions

So what you're saying is, its okay to get a job if its towards a shared goal, not to enrich yacht dude. Lots of people get those sorts of jobs already, so tell us something new.

# ¿ Nov 1, 2015 04:09

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Barnyard Protein posted:

changes are normal right? or does that mean "Clients may decide they want to change the spec they just handed you after you've implemented it, causing you to redo all the work you just did"

This is pretty much why for my little dev/design shop we don't quote, we estimate and give them a budget of hours to work with.

Because getting them to be happy with committing to a spec is nigh on impossible, and were not keen on being left holding the bill because of an overrun on communication or reimplementation.

# ¿ Nov 5, 2015 20:39

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

GPF posted:

i guess my question is this: what is the actual benefit of having immutable objects/lists/vars/strings? i've gotten the understanding that everything in functional langs like f# are immutable, but what's the benefit? why is that a good thing?

The benefit is predictable behaviour in a far wider range of contexts. Like Valeyard said, concurrency becomes easier to reason about, but its much more than that.

When you read code, you are assured that function calls just return new values (never quietly altering the input values), that assignments of variable names are final in that block of code, that operations are not destructive unless you lose the reference to the immutable object.

That might not sound like much, but it makes life far simpler in terms of building simple reusable functions that won't fall down because of tricky edge cases. Adopting a functional programming style (value in, value out, no side effects) goes hand in hand with immutable objects, instead of mutating lists and maps you get used to other strategies such as:

- mapping: change elements to something else
- filtering: drop elements based on a predicate
- reduction: combine elements into a single value

You'll need to shift gears to think like this, especially with looping code where you may need to use recursion, but once you do you'll recognise that even in largely imperative languages there are ways to simplify code by treating values as immutable.

Immutable offers performance optimisations as well, given that equality can potentially be deduced more cheaply via reference, deep trees don't need to be fully compared. Parts of trees are their own immutable objects and don't need to take up additional space in memory. Functions without side effects can assume the same immutable argument provides the same immutable return value. Lazy infinite structures can potentially be created because we are guaranteed predictable results no matter how many are taken.

In a nutshell, accept some limitations, alter your thinking, and immutable objects will deeply change the way you write and debug code. (but probably cause you spending more time thinking about how to write it, which isn't necessarily a bad thing)

# ¿ Nov 7, 2015 19:27

Adbot: ADBOT LOVES YOU

# ¿ May 11, 2024 10:41

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

MALE SHOEGAZE posted:

the speediness of vim is totally ruined by the fact that syntax highlighting frequently brings it to a crawl

i say this as a vim user

Yeah, most languages don't have this problem, however whenever I'm stuck editing a yaml file the whole thing noticeably crawls, that parser in vim is so god drat slow.

# ¿ Nov 18, 2015 22:33

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›4 »