Brawndo, with electrolytes it’s got what plants crave
251 karma · joined April 7, 2017
Who will make the components for you to copy and paste to cobble together more crufty kluge of examples that justifies your over the top assertion?
This also allows you to put hooks in to track users of the old api version so that additional reach out/communication to the slow adopters can be had.
The truth of the matter, is even if you are more technologically ahead, on par or behind you counterparts in a company you are screwed when you are not liked.
There are only a handful of people I have met that are truly honest, with themselves and others. In which leaves everyone else never being capable of accepting new or different ideas, or to the point any type of criticism because they honestly can not do a self reflection.
People are more likely to believe in lies, than the truth.
If you find yourself not being liked, regardless of the reason you became not liked it is time to go. Be it on day one, or day 999+
If you find your suggestions, comments, criticism, are not received, do not argue with idiots and try win your case with a follow up. If they were not receptive with a feel-felt, or pathos,ethos,logos forms of communication then your going through and exercise of futility.
My suggestion for anyone before even thinking of accepting a new position, during the interview ask the following,
1.why is the position open? Growth? Replacement of a but in a seat? If the later; ask was it a resignation or a termination.
2. Ask could I have or see a employee handbook? You can gleam a lot about company culture just by reading. Red flags on things like dress code restrictions (when the position my not ever be public facing). Ie a long exhausting list of can not wear. Unfair things like banning shorts, but not banning skirts. Dress code should be just stated by job role, business professional, business casual, relaxed business casual, casual. Look for phrases/wordings that might lend towards management deciding to not deal flexibly per employee, as that the management/leadership has taken a stance that a past employee ruined it for everyone style. Look for anything that will make you uncomfortable working there.
3. Ask for their SDLC documentation/process/methodology, coding style guidelines, and the technology stack they use? If the can’t produce or speak in detail or are vague on details. another red flag, that they might be cowboy coding, silo building, bus factor of one per process, etc... you want to make sure you are not walking into a environment with a nightmare scenario where it is a one to one of a single dev to a project and only that dev touches/knows anything about it. As that there is typically resource constraints, poor to no time allocation for code revise,testing, documentation. As well a the technical debt/corner cutting that goes along with not having good project/sdlc management practices.
4. What is the process for changing the any of the current sdlc, methodology,practices, guidelines,etc...? Explain that you’ll be the fng (freaking new guy/gal) and that you will be bringing your knowledge in, as well as absorbing the new to you sdlc,process,yadda yadda and you want to understand how new and possibly different ways of doing things (innovation) is incorporated. You are trying to spot what the parent article fell into, by avoiding becoming the unliked team member. You also want to know if the think the word “standard” means etched in stone, never changing. Standards do change, and are revised. I have never seen a standard that does not have a revision number.
5. Blantently ask; what is your stance on open source software? Followed up with what is your take on Microsoft moving to open source and being a Linux foundation member? You want to make sure you know if they are current in the tech news and events. You want to make sure they are not using dead technology stacks, or SSIS for things beyond it’s intention,or have drank the MS kool-aid from 10-20 years ago and missed the memo that they were wrong about Linux being a cancer. Your also trying to spot the I got a tech job mindset, I know only XYZ and have lost the ability to learn and stay up to date with current trends in the industry. IE there is no such job title as database admin, database administration is a hat/role the devOps, software engineers wear when needed. You do not want to find yourself having to use ssis for application development when it is a database management tool, or having to maintain sql stored procedures that on average 5000~ lines long because they only learned t-sql. You are trying to spot if the company is a right tools for the right job, or we spend 200,000 on a hammer so everything is hit with the hammer.
Final thoughts; to avoid the problems I once encountered as well as what the parent post went through. Walk-in to any interview you get with the mindset of “You are interviewing them, they are not interviewing you.” Go in with good questions about the company, culture like I suggested above to see if they are a good fit for you and the working conditions you want to work or work best under. Be honest, be humble, don’t bullshit, and it’s ok to say I don’t know I would have to research and learn. End of the day, If the answer seems like a no, then it’s a no, don’t waste your or their time.
Common sense was out the window in this article when it was written.
The TL;DR; Do document your design by stating the method/function/classes purpose, state your inputs, state your return states. Try to be consistent. Avoid creating ambiguous states, where your co-workers or future developers have to guess what is correct when they use your code.
My opinion is that methods/functions/classes should have documentation stating their purpose and design. Many languages have built in documentation generators or are supported by external generator projects like Doxygen.
Above your method/function/class just put the syntax for your documentation engine. state what your thing does. state the input parameters, state the returns (which includes documenting the success states, and the error states). Bonus points for having a usage example on how correctly use the method/function/class.
just doing this I feel is the bare minimum for future developers to be able to pick up from where you left off. It is like declaring an outline just like writing an english paper. State the purpose for your code.
Now as far as the code itself; Yes by all means write clean and self documenting code. You do not need inline comments as a general rule. However, sometimes you have requirements from a customer and there is complex business logic. Having documentation in the code of an algorithm or business steps can be very helpful.
Complete lack of comments on return states can cause future bugs. A example is a recent project in which I took over for a customer for their websites web service back end, does not have any comments. There are bugs and errors, since my predecessors did not document return states it is hard to tell what the effect of a fix will be. In one particular case, there is a null reference where the variable has check before use, which is used to populate later data. This particular method returns a array of object. The grey area here is what should be returning in the failure state.
What do we return to fix the overall error?
A null Array of objects?
A instantiated but empty object with null components?
A instantiated array object that is empty but containing no nulls (nulls fixed to zero length strings or zero)?
A instantiated array object with the data populated for what we do have and nulls for what we don't have?
A instantiated array object with the data populated for what we do have and no nulls, empty strings and zero's?
As the code is currently, we can not answer this question because each return case is technically correct. Looking at the references upstream we see the method in question being used differently, some cases there checking for a null return, some there checking null components, some checking for empty strings or zero, etc...
This mess, all stems from the original developer not defining or stating the success states and failures on the returns and the example usage in the codes documentation. what is worse is that in other area's of the code the same developers are doing similar logic, but employing yet another return scheme. What is worse than all of that, the method in question, is being used by the same developer (that they wrote) with different return checks. (I guess they slept since then... forgetting how their own code works).
The point is that it is unclear. Looking at the code, yes it is self documenting, fairly clean code, and not written poorly when you just focus on individual chunks. However as a whole the code is not consistent, has lots of guess work/assumptions made which makes for lots of bugs.
This project has been a total refactor, clean up job, in which the my client is happy for the better results, but is feeling the pain of previous less than quality work done by the "popular" in town development house.
I would suggest adding the use of Doxygen to your projects. It supports Markdown files as well as Markdown syntax in your code comments. You might find that a lot of what you are documenting in the separate .md files could be a notes or remarks section of your method class comments. This will remove the separation of technical documentation vs. help/FAQ comments by doing all of the documentation in the code. You can then add Doxygen to your build, so that building the project refreshes the documentation. Doxygen can be configured to produce a online html version that can be deployed to an internal web server for quick reference. It can also build .pdf, rich text documents, and unix man pages.
Then if you use Continuous integration/deployment, when you deploy to test, UAT, then eventually production you deploy the official documentation that was generated.
The challenge with all documentation, is, Actually doing it. So it should be part of your SDLC documentation and process. the project/task/request is not done until documentation updated. Make it a checklist item that needs to be reviewed in code reviews. Doing the technical and help/FAQ all in code comments makes that easy.
cheers!
1. use a dedicated browser, and only use that browser for this site.
2. utilize private mode if you don't want to dedicate a browser only for this site
3. use different profiles in your normal daily browser. for example firefox, and chrome allows you to have multiple profiles. Create a new profile to use when going to this site.
4. analyze the javascript and see if it is coming from a 3rd party/CDN url. if so download the javascript files, modifiy it to just return a success state, etc..., deploy it to your own server running apache or nginx. clone the URL structure on that server. then edit your hosts file to cause your computer to point that host in the url to your own server, serving up your modified version of the .js files.
5. least level of effort: Get a different credit union.
those who don't understand Unix are doomed to re-implement it, Badly.
In truth though this book seems to be a satire, and a comment about things to try to avoid doing in a Unix based operating system and crazy things Users have done, and the pitfalls/gotchas Users have found themselves in.
just like you should never type `rm ` in a directory. The same could be said for dos don't type `del ` same behavior.
it's a pretty good read, and kind of comical in 2017.
Code without comments is very bad. There is no such thing as self documenting code. You have to consider who will be making modifications to the code after you, and that your comments sole purpose is to convey the fundamental design of your code.
document the purpose for the code, document the inputs and returns, document the algorithm steps when appropriate. Do not put a comment on every line. Just comment the unclear or potentially fuzzy bits.
also on a side note, if your code is slick and clever and requires a comment to explain it because it is complex and cryptic. You Failed!
Our life is frittered away by detail... simplify, simplify, simplify. --Henry David Thoreau
Guns do not kill people. Unstable disturbed people kill people. It is not the tool used to cause death, it's the person that wields it. We still haven't solved a core problem of our species, but we have invented easier ways to kill each other.
Stop blaming the Guns, bombs, swords, sticks and stones. start looking at the real problem.
like this:
https://productreviewsbychristina.files.wordpress.com/2017/0...
I have hooks on the window above my sink, on the outside of the exhaust hood above the stove, on the fridge door, and on the inside of a select cabinet door that can be angled. just have to slide the tablet out, and move it where I need it. Don't have to worry about spills and damaging it because it's not on a counter or table and it's out of the way and eye level.
it's great for looking at recipes, using a Timer app, and watching Netflix while cooking and or doing the dishes.
I'm on the hunt for a decent bluetooth in oven thermometer and app. Anyone have any suggestions?
The state of programming is currently a mess. 20 years ago there was not so many topics and programming techniques. back then you started with Basic programming to get your feet wet. You would move on to other high level languages like C/C++, Java, etc...) Developers older than me would have learned C/C++, Fortran, Pascal, Lisp etc...) There was a clear learning path without too many branches to go down.
Now a days, you have terms like UI/UX designer, Front-end developer, back-end developer, full-stack developer, embedded systems developer, etc...
These are all new concepts, back in the day it was just developer or software engineer.
Todays landscape has too many things to wrap your head around - HTML, Javascript, Nodejs, Go, Rust, Scala, CSS. Ruby on Rails, React, yadda, yadda, on and on and on...
So it is easy to understand it's hard to find out where to start.
The truth is; all of these programming languages all build upon basic principles. Assignment of data, mathematics( arithmetic, calculus, algebra, etc...) , and most importantly Boolean algebra which gives us true and false, AND, OR, NOT, XOR, XAND, NOR, NAND, etc.. Boolean algebra or sometimes called Boolean Logic lets us form Conditional logic/statements ( if statements, equals, greater than,, and loops (do, while, for, foreach, etc..).
to recap the basics of programming are:
1. assignment of data to a variable. X = 1; Just like algrebra. Put your data in a bucket with a label. 2. operations on that data: mathematics, inputs and outputs (I/O), etc...) Do something with that data, which may create more data to store. 3. Conditional statements to decide what to do next with the data: if ( x = true) let y = 2 + 2; do while (y == 4) then y = y -1 end
So... My advice is learn the basics of programming. Do not get hung up on a "Buzz" word/topic/language. Pick a language and master the basics.
Programming languages could be said to generally come in 3 flavors. and 2 sizes. The official terms are paradigms and types. Note that there are more paradigms and types, but to keep it simple these are the most common/basic.
Flavors (paradigms)
1. Procedural - (do step 1, then 2, then 3 in a defined order) 2. Object Oriented ( a very simple definition: objects are generic, reusable chunks of code that try to describe real world concepts. Once objects are created, what those objects can do are executed. define Object boy: the boy can jump, the boy can sit. create new boy. boy.jumps boy.jumps boy.sits ) 3. Functional - just like higher mathematics that have the concept of functions. f(x) = y +2 f(y) = 3 - a f(lambda)= f(x)(f(y)(a=1)). You define your functions, then the global function typically called the lambda function is where the program starts it's execution.
Sizes (types):
1. Compiled/assembled - languages are read by a program and turned into a file that is executable by your operating system. To run your program you ask your operating system to run the code in that file. your code is converted from the language you wrote it in and converted to machine binary (zero's and ones) that your CPU can understand. That binary (zero's and ones) is saved as a file for later use ,and reran quickly.
2. Interpreted - you run a program and give it your code as you wrote it, and it runs the steps in your code. it is not saved for later use. Every time you want to run your code, the work of converting your code to Binary is done again. Interpreted languages will sometimes have a runtime, A runtime is the program that executes your code on your machine. Interpreted languages are slower than compiled languages.
I would suggest picking a compiled programming language. Preferably on in the C syntax family (C, C++, or D). Pick up a book on one of these languages written for beginners. Read the book and work through each example/tutorial/assigment. This is the harder route, because you will have to learn the compiler and associated tools sometimes referred to as a "toolchain" You'll have to learn how to run the compiler, what program/tool you type your code into, etc...
I would also suggest Installing Linux or using a Mac. Stick to open operating systems that are of the UNIX family. Find open source applications that suit your fancy read the source code to learn more. This is one of the reasons Open source is king. You can use the force by reading the source.
Programming is not easy, it is not meant to be. You have to fall in love with computers, and learn not to give up when something is not working. Solving complex problems starts with learning from cryptic compiler warnings and errors. It will force you to find your mistakes, and avoid them moving forward. it's like negative reinforcement, you just want it to work, eventually it clicks and you can write tons of code and have it compile on first go. Does not mean it works as designed, but works as you wrote it.
After you have a firm grasp on the concepts, rest is just syntax. What do I mean by that? every language has assignment of data, operational statements , and conditional statements. It's just how you type the code that is different so it works. Learning a new language is then just re-learning how to express the basic concepts in code and run that languages toolchain.
you should not concentrate on web, mobile, embedded at first. Learn to crawl, then walk. Then again find open source projects in those area's and see what you like. If you dabble with them all you will be well rounded and won't sweat any job that comes your way. ultimately you might like embedded, or systems programming.
In reality though, you'll do what ever work you can find a job doing. knowing more languages, and being able to answer tough interview questions will really determine what you end up doing. My advice to you is once you adept at writing code, it's not what you like doing at work. It's about what pays the bills. You can always work on what you want to do on the side.
I would first brush up on actual MVC concepts and truly under stand the 3-tier architecture design patterns. The C# MVC framework hides some crucial concepts away from the application developer. I would also brush up on CGI and FCGI programming just to get a bigger picture of how things are/were done. Then make suer you have a firm grasp on the HTTP protocol etc... Understand RESTful webservices, SOAP webservices, start looking at RPC ( webservices not over http).
Then... I would find a crash course on Unix/Linux, Linux acadamey, youtube lectures, books ("running linux" is a good primer), search .edu sites for online course materials, etc...
Third install a linux distrobution. spend some time with it getting comfortable with the command line. Then install a different distrobution and keep "distro hopping". The goal is to find the one you like the best and use that for your projects. My first distor was Slackware back in 94. then I landed on RedHat, then I ran Mandrake, then Debian, then proper Unix (freeBSD) for awhile. I currently run Ubuntu at home.
I bring this up because I have clients that run Mac's, other clients on CentOS/RHEL. You never know where your code is going to run. Especially since Python and Ruby can run on many different platforms.
I should also suggest that you read the Linux from scratch documentation. This will help you get a firm grasp on how a GNU/Linux system is put together. then at some point in your life actually build a LFS system.
The reason is so you can understand that not all GNU/Linux systems have the same tools. That there are some overlaps and but some major differences (like location of logs, install paths, package management) doing things in Debian is different than Fedora/Redhat, which is different than Suse.
Yes what I said above will take time to learn. Think of this as a side quest towards your ultimate goal. The skills you will learn along the way will help with all future endevors with doing Linux/Unix development.
Once you have a Linux distro installed, go through the process of setting up Apache. Then Nginx. Essentially set up a basic LAMP stact. While your goal is Python/Ruby there is some overlaps, and it will give you the basic skill set of administrating those environments.
Next install Python and Ruby. Start going through tutorials Build some things.
Remember there are many ways to do web development, and there are pros and cons to each way. Just keep learning, Sometimes a new way of doing things comes out of other area's. A good idea is a good Idea, Being able to take what you know from C#, or something say the NodeJS folks are doing and implementing it in Python/Ruby could be a very good thing for those languages.
Also here are some other topic you might want to look at:
* learn how to use the man program. run $ man man * using different shells, csh, bash, etc... there scripting languages. Learn to not be afraid of the command line. * build tools: make, autotools, cmake, etc.. build some software from source code to understand how different projects are put together. * compilers: gcc, clang/llvm * debugging tools: gdb, strace, dtrace, etc... * system monitoring: top, htop, iotop, glance, free, df, du. * system administration tools: kill, ps, ip, ufw, etc... it's nice to know how to find and shutdown a runaway program. also nice to know how to get your IP, opening and closing ports in the firewall. * learn how to use curl. So that you can test hitting a url from a commandline. curl with a bash script can automate some of your testing/debugging. * learn how to set the sshd and using ssh to remotely connect to other machines.
Some final thoughts; Find your learning resources. Find tutorials on the topics you want to learn. Look at .edu sites as that you can find free course materials and lectures. Look for lectures on youtube, start listening to Linux/Unix podcasts for new topics and news. Put together a reading list on the topics you want to learn (also keep in mind that just because the book is old doesn't mean it's useless). I have many books that discuss the inner workings of protocols that newer books on the same topic leave out.
Lastly, have fun while you are storming the castle, Don't make this into a job/work or you will get burned out.
Reflection is something you do. so by doing the action of reflection you can gain insight on what to do next time around.
Wisdom is earned by doing, not by aging.
object MAX_TWEET_CHARS { val value = 140 }
to
object MAX_TWEET_CHARS { val value = 280 }
and a re-compile.
Again, hopefully they had their code base in order and it was simple as changing a static setting, with a single line of code change.
20-30 hours - does this include a Unit test framework, a code review process, QC front end testing, security considerations, documentation? Probably not. Again you get what you pay for.
if you cut too many corners, you will have a circle and it will eventually come back on you, which you will pay for your decisions.
#define MAX_TWEET_CHARS 140
to
#define MAX_TWEET_CHARS 280
and a re-compile.